De que é construída uma reunião do InterMIND
Quase todo produto é construído a partir da mesma stack padrão — os grandes SaaS proprietários para os quais todo mundo recorre. São o caminho sem atrito. Em cada camada onde os dados da sua reunião de fato vivem, escolhemos um caminho diferente: nosso próprio código, ou open source que pudéssemos auto-hospedar.
Este é o complemento de Onde uma reunião do InterMIND realmente é executada, que mapeou a geografia — onde cada serviço roda e quais dados passam por ele. Este post responde à próxima pergunta que uma equipe de segurança faz: de que isso é feito — e podemos ler, auditar e substituir?
Não onde roda — do que é feito, camada por camada.
Os padrões e o que eles custam
Todo produto é uma pilha de escolhas. Para a maioria dos produtos, a maior parte dessas escolhas é feita por padrão: Google Analytics, Firebase, a API do Google Translate, Auth0, React. São o caminho sem atrito, e para a maioria das equipes essa é uma decisão razoável. A contrapartida é que cada uma coloca uma parte da sua stack atrás de um fornecedor que você não consegue ler, não consegue auditar e do qual não consegue sair sem uma reescrita.
Fizemos uma escolha diferente em cada camada onde os dados da sua reunião realmente vivem: nosso próprio código, ou software open source que pudéssemos auto-hospedar. Onde uma camada não toca no conteúdo da sua reunião, somos pragmáticos e dizemos isso. Aqui está o quadro completo.
A espinha dorsal: o engine é nosso código, não de um terceiro
Comece pela camada que mais importa, porque a maior parte da sua reunião passa por ela. O transporte em tempo real e a tradução de voz/chat rodam ambos em mind-sdk + a Mind API — nosso próprio engine, na OVH França. A maneira padrão de construir uma reunião traduzida é acoplar um SaaS de tempo real (LiveKit) a uma API de tradução (DeepL, Google); não rodamos nenhum dos dois no caminho ao vivo. Nenhum modelo de tradução de terceiros está no circuito. (Usamos sim o DeepL — mas só para documentos enviados ao chat, não no caminho ao vivo de voz/chat; veja o mapa de runtime. Cobrimos a mecânica do pipeline em Por dentro dos quatro pipelines de tradução.)
Aqui está a parte que não está no mapa de runtime: o SDK no qual sua reunião roda é open source sob a licença BSD 3-Clause — o cliente mind-sdk é público em gitlab.com/mindlabs/api/sdk, copyright MindMeeting OÜ, nossa entidade de IP estoniana. Ele se comunica com a Mind API em api.mind.com, que rodamos nós mesmos na OVH França.
Isso não é um arranjo "olhe, mas não toque" do tipo source-available. BSD 3-Clause é uma licença permissiva, aprovada pela OSI. Sua equipe de segurança pode clonar o SDK, ler exatamente como seu áudio e texto são capturados, encapsulados e transmitidos, e auditar essa integração contra os seus próprios requisitos. O engine do lado do servidor com o qual ele conversa é nosso — não a caixa-preta de um terceiro — e um engine totalmente auto-hospedável para o tenant que precisar dele está no nosso roadmap, não é algo que oferecemos hoje. Atualizaremos este post no momento em que ele for lançado.
Camada por camada: o padrão vs. o que rodamos
| Camada | O padrão usual | O que rodamos | Por que isso importa para você |
|---|---|---|---|
| Engine de tempo real + tradução (voz + chat) | LiveKit + uma API de tradução (DeepL / Google) | mind-sdk (cliente BSD-3-Clause) + nossa Mind API, OVH França | O fluxo de dados mais pesado é nosso próprio engine, não o modelo de um terceiro — e seu SDK cliente é aberto e auditável |
| Framework de frontend | React (Meta) / Next.js | Vue + Nuxt | OSS governado pela comunidade — nenhuma corporação isolada é dona do framework no qual sua UI roda |
| Analytics de produto | Google Analytics | PostHog | Open source, cloud na UE, com proxy first-party por meio do nosso próprio domínio — dados de uso não fluem para uma plataforma de publicidade de terceiros |
| Fontes | CDN do Google Fonts | Auto-hospedadas (@nuxt/fonts) | Sem chamada de fontes de terceiros a partir da página que seus usuários carregam — um achado recorrente em GDPR, evitado |
| Autenticação | Auth0 / Clerk / Firebase Auth | OIDC próprio, federado ao seu Google / Microsoft | Nenhum intermediário de auth guarda suas sessões — você traz seu próprio provedor de identidade |
| Tradução de documentos | Google Translate | DeepL (Colônia) | Fornecedor especializado da UE, processamento alemão |
| Conteúdo / docs | Contentful / Sanity (CMS headless) | Nuxt Content (markdown versionado no git) | As palavras no nosso site vivem no nosso repositório, não no banco de um fornecedor |
| Banco de dados da aplicação | Firestore / DynamoDB (proprietários) | Postgres (no Neon) | Padrão aberto — portável para qualquer host Postgres, sem API de consulta proprietária para reescrever |
| Object storage | APIs de blob proprietárias | Tigris (compatível com S3) | Protocolo aberto — gravações e exportações são portáveis para qualquer store S3 |
| CRM / vendas | Salesforce / HubSpot | Pipedrive (estoniano) | Registros de clientes e negócios ficam num CRM domiciliado na UE, não numa plataforma de vendas dos EUA |
Dois fios atravessam essa tabela. Open source onde a ferramenta processa seus dados — para que possa ser auditada e, em princípio, auto-hospedada. Padrões abertos (Postgres, a API S3, OIDC) onde dependemos de infraestrutura — para que nada fique preso ao preço ou à postura de conformidade de um único fornecedor. Postgres pode ir para qualquer host Postgres; storage pode ir para qualquer store S3; auth federa para o provedor de identidade que você já roda. A última linha está num terceiro eixo: o CRM que guarda os registros de clientes é domiciliado na UE (Pipedrive, estoniano) em vez de uma plataforma de vendas dos EUA — não é open source, mas também não está sob jurisdição dos EUA.
Algumas dessas merecem uma frase a mais. O PostHog é open source e auto-hospedável; nós o rodamos na cloud da UE da PostHog e fazemos proxy first-party pela nossa própria origem, de modo que os eventos não são silenciosamente bloqueados por ad-blockers e não trafegam por um domínio de analytics de terceiros. A autenticação nunca vai para um SaaS de auth de terceiros que ficaria entre você e suas sessões — rodamos o fluxo OIDC nós mesmos e federamos para sua identidade existente no Google ou Microsoft. E as fontes em cada página são servidas a partir do nosso próprio domínio; o único lugar em que o Google Fonts aparece no nosso código é um script offline de assets de marca, nunca o app que seus usuários carregam.
Onde somos pragmáticos — dito em voz alta
Não fingimos que toda a stack é feita à mão ou não americana. Não é, e um post que dissesse o contrário seria contradito pelo nosso próprio mapa de runtime.
O encanamento — hospedagem e SSR (Vercel), o compute do servidor de reunião (Fly.io), pagamentos (Stripe), e-mail transacional (Resend) — roda em SaaS domiciliados nos EUA. Stripe e Resend cuidam de faturamento e convites e nunca veem conteúdo de reunião. Vercel e Fly são compute alugado: nosso próprio código roda neles, e o servidor de reunião na Fly de fato lida com a sessão ao vivo e com a transcrição que nosso digest lê — mas isso é nosso código nas máquinas deles, não um produto de fornecedor ingerindo sua reunião. Tudo isso executa na UE em runtime (o assunto do mapa de runtime).
Esse é um trade-off deliberado e delimitado: ser dono e tornar open source o data plane; usar o melhor SaaS disponível para o control plane. Nomear isso é o ponto — "soberania" significa pouco se as exceções não estão sobre a mesa ao lado das vitórias.
As etapas de IA pós-reunião, e o plano
Nenhum modelo proprietário domiciliado nos EUA toca conteúdo derivado da reunião. As etapas de modelo de linguagem que rodam depois da chamada — o digest de IA (tópicos, decisões, itens de ação), o resumo pós-reunião e o editor de notas com IA — todas ficam em processadores da UE. O digest e as ações generativas do editor rodam no Mistral hospedado na UE com zero retenção de dados (acessado via AI Gateway da Vercel, fixado ao provedor Mistral). O resumo e a ação traduzir do editor rodam no nosso próprio engine na UE na OVH — o mesmo por trás de voz e chat ao vivo. Voz em tempo real, chat, notas e documentos nunca passaram nem perto de um LLM de propósito geral em primeiro lugar.
O único modelo dos EUA ainda no circuito julga nosso benchmark público de tradução — pontuando traduções automáticas de sentenças de referência fixas do FLORES-200, nunca a reunião de ninguém.
Estamos indo ainda mais longe nas etapas com Mistral na UE: um opt-out controlado pelo dono para desligar o digest por completo, e um modelo de sumarização open-weights auto-hospedado na OVH (classe Kimi) para substituir o Mistral externo. O ponto da rota open-weights não é qual laboratório treinou os pesos — é que pesos abertos podem rodar em infraestrutura que controlamos, o que os mantém no mesmo eixo aberto-e-auto-hospedável do resto do data plane. Ambos estão no roadmap, não foram lançados; atualizaremos este post quando chegarem.
Por que isso importa além de nós
Isso não é engenharia por si só. A razão para construir uma stack desse jeito aparece do seu lado do contrato:
- Auditável. O SDK no qual sua reunião roda é código open source que sua equipe de segurança pode ler, e o engine por trás dele é nosso — não a caixa-preta de um terceiro.
- Portável. Padrões abertos em cada camada de dados — Postgres, S3, OIDC — significam nenhum lock-in proprietário. O que pode ser movido não está amarrado a um único fornecedor.
- Auto-hospedável. As camadas de dados em padrões abertos — Postgres, S3, OIDC — já rodam em infraestrutura que você controla; um engine de tradução totalmente auto-hospedado está no roadmap para o tenant que precisar dele.
Este é o quadro em 2026-06-07. Vamos atualizá-lo quando a stack mudar — uma troca de fornecedor, uma camada reconstruída, o modelo do digest substituído. A configuração atual é verificável em nosso vercel.json aberto, em nosso nuxt.config.ts e no repositório mind-sdk em BSD-3-Clause linkado acima.
Se uma camada aqui parecer errada, ou se sua revisão de segurança precisar de uma resposta que este mapa não dá, escreva para nós. Preferimos corrigir um detalhe faltante a deixar você encontrá-lo numa auditoria de código.