Onde uma reunião do InterMIND realmente roda
Toda conversa séria de aquisição corporativa acaba chegando à mesma pergunta: "Para onde vão esses dados?" O DPO quer uma lista de subprocessadores. O CIO quer saber quais fornecedores têm domicílio nos EUA. O jurídico quer um diagrama com setas.
Preferimos que você tenha o quadro completo do que ir entregando aos poucos 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 de deploy real em 2026-05-28.
Todo caminho que toca conteúdo de reunião é UE em tempo de execução — incluindo as etapas de IA pós-reunião, que antes apontávamos como a única lacuna e que desde então migramos para processadores da UE. Dizemos claramente onde fica o único modelo nos EUA que ainda usamos, e por que ele nunca vê sua reunião.
Este post mapeia onde sua reunião roda. Seu post companheiro, Do que é feita uma reunião do InterMIND, mapeia do que ela é feita — quais camadas são código nosso, quais são open-source e onde somos pragmáticos quanto a SaaS proprietário.
O que "onde roda" realmente significa
Duas coisas se confundem em conversas sobre soberania e não são a mesma coisa:
- 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, na prática, as regulações de residência de dados e a maioria dos DPAs.
- Domicílio corporativo 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 exigência dos EUA contra a entidade-mãe do fornecedor, independentemente de onde a carga de trabalho roda.
Quase toda pergunta do tipo "isto está na UE?" é, na verdade, uma dessas duas, formulada de forma imprecisa. Respondemos cada uma separadamente para cada fornecedor abaixo.
O caminho dos dados de uma reunião
Acompanhe uma chamada do ingresso até o e-mail de follow-up:
- 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. - O WebSocket conecta ao nosso servidor de reuniões em Paris (
cdg). Orquestração de reunião, presença, sinalização — tudo na UE. - O reconhecimento de fala roda no navegador de quem fala. Local. Nunca sai do dispositivo até que a transcrição resultante seja enviada para tradução. (Explicamos o porquê em Por dentro dos quatro pipelines de tradução.)
- Tradução de voz e chat chega ao nosso próprio motor na OVH França. Este é o
mind-sdk+ a API Mind — nosso código, nossos hosts, na França. Nenhum modelo de terceiros está no caminho. Orçamento de sub-segundo, pool de WebSocket por idioma, residente na UE em cada salto. - Um documento solto no chat (PDF, DOCX, PPTX, XLSX) vai server-side do ws-server em Paris para o DeepL em Colônia. Empresa alemã, processamento alemão. Voz e chat não passam pelo DeepL.
- Dados da aplicação — usuários, equipes, mensagens, metadados de reunião — ficam no Neon Postgres no AWS Frankfurt (
eu-central-1). Snapshots na mesma região. - Gravações, anexos e exportações são armazenados no Tigris, armazenamento compatível com S3 na Fly. Replicado na borda; o bucket é configurável para multi-região UE para tenants que precisem fixá-lo de forma mais restrita.
- 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. - Analytics de produto vão para o PostHog EU (
eu.i.posthog.com). - E-mails transacionais (magic links, convites, recibos) vão 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 realmente flui — também é nosso próprio código, não de terceiros. O SDK cliente em que ele roda é open-source (BSD-3-Clause) e auditável hoje; auto-hospedar o próprio motor está no roadmap para um cliente que precise disso.
O mapa de fornecedores
| Fornecedor | O que faz | Local de execução |
|---|---|---|
OVH (mind-sdk + API Mind) | Motor de tradução de voz + chat | França |
| Fly.io | Orquestração do WebSocket da reunião | Paris (cdg) |
| Vercel (Nuxt + APIs Nitro) | App shell, APIs de servidor, SSR | Frankfurt (fra1) |
| Neon | Postgres da aplicação | AWS Frankfurt (eu-central-1) |
| Tigris | Armazenamento de objetos (gravações, anexos) | Replicado na borda; fixável na UE |
| DeepL | Tradução de documentos (PDF/DOCX/PPTX/XLSX) | Colônia |
| Sentry | Rastreamento de erros | de.sentry.io (UE) |
| PostHog | Analytics de produto | eu.i.posthog.com |
| Resend | E-mail transacional | Irlanda (eu-west-1) |
| Stripe | Pagamentos | Irlanda (Stripe Payments Europe Ltd.) para clientes da UE |
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, por acaso, os dois fornecedores cuja entidade-mãe está na UE. Isso cobre a maior parte do conteúdo de reunião. A lista completa de subprocessadores com detalhe de domicílio corporativo entra no DPA como prática padrão; a tabela acima é a visão de runtime, que é o que a maioria das cláusulas de residência de dados aborda.
As etapas de IA pós-reunião, ditas claramente
Depois que a chamada termina, rodamos algumas etapas com modelos de linguagem sobre o que foi dito: o digest de IA (tópicos, decisões, itens de ação, perguntas em aberto), o resumo pós-reunião e o editor de notas com IA (traduzir uma nota, ou corrigir / expandir / simplificar). Estes são os únicos lugares onde um modelo de propósito geral toca conteúdo derivado de reunião — e todos eles agora rodam em processadores da UE:
- O digest roda em Mistral hospedado na UE (
mistral-large-3, com fallbackmistral-medium-3.5), acessado pelo AI Gateway do Vercel fixado no provedor Mistral com zero retenção de dados — a requisição falha em vez de cair para um host não-ZDR ou nos EUA. - O resumo e a ação de traduzir do editor passam pelo nosso próprio motor na UE na OVH — o mesmo que traduz voz e chat ao vivo — de modo que o resumo nunca sai do plano de dados em que a reunião já vivia.
- As ações generativas do editor (corrigir, expandir, reduzir, simplificar, resumir) não podem rodar num motor de tradução, então usam o mesmo caminho Mistral UE + zero retenção de dados que o digest.
Voz em tempo real, chat em tempo real, notas e tradução de documentos nunca passam por nada disso — eles foram residentes na UE desde o início.
O único lugar em que um modelo com domicílio nos EUA ainda está no circuito não toca nenhum dado de reunião: nosso benchmark público de qualidade de tradução usa um modelo de fronteira como juiz automatizado, pontuando traduções automáticas de frases de referência do FLORES-200. Esse é um dataset fixo e público — não a reunião de ninguém.
Ainda estamos indo além nas etapas com Mistral UE: um opt-out controlado pelo proprietário planejado para desativar o digest por completo, e um modelo open-weights auto-hospedado (classe Kimi) na OVH para substituir o Mistral externo em tarefas de sumarização que não precisam de um raciocinador de fronteira. Ambos estão no roadmap, não entregues; atualizaremos este post quando chegarem.
O que isso significa para o seu DPA
Para a maioria dos compradores da UE — Mittelstand alemão, indústrias reguladas rodando DPAs padrão de GDPR — o quadro acima responde diretamente à pergunta de residência de dados: cada salto de runtime que sua reunião faz está na UE. O domicílio do fornecedor é divulgado na lista de subprocessadores conforme prática normal; nada surpreendente ali. O mapa de residência é uma peça; para o restante das obrigações de proteção de dados — apagamento, retenção, portabilidade, consentimento — passamos a base de código por uma auditoria completa e fechamos cada item contra o código.
Para a souveraineté numérique francesa e aquisições de nível SecNumCloud, o domicílio corporativo do fornecedor é, em si, parte do critério, não apenas o local de execução. Essa é uma conversa diferente — uma topologia de implantação 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 quando o contrato justifique o esforço.
Para compradores nos EUA e na maior parte da APAC, o inverso costuma ser verdadeiro — eles querem baixa latência a partir de suas regiões, o que é um problema diferente. Hoje rodamos em região única em fra1. Se o seu tráfego justificar uma borda nos EUA, planejaremos isso com você.
A que este post nos compromete
Este é o quadro em 2026-05-28. Vamos atualizá-lo quando o 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 + API Mind rodando na OVH França, e no dashboard de cada fornecedor.
Se algo aqui parecer errado, ou se seu DPO precisar de uma resposta que este mapa não dá, escreva para nós. Preferimos corrigir um detalhe faltante do que ter você descobrindo isso numa revisão de contrato.