Do que é feita uma reunião no InterMIND

Quase todo produto é construído a partir da mesma pilha padrão — os grandes padrões de SaaS proprietário que todos adotam. Eles são o caminho sem atrito. Em todas as camadas onde os dados da sua reunião realmente vivem, escolhemos um caminho diferente: nosso próprio código, ou código aberto que podíamos hospedar nós mesmos.

Este é o complemento de Onde uma reunião no InterMIND realmente é executada, que mapeou a geografia — onde cada serviço é executado e quais dados passam por ele. Este post responde ao que uma equipe de segurança pergunta em seguida: do que isso é feito — e podemos ler, auditar e substituir?

Não onde é executado — 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 maioria dessas escolhas é feita por padrão: Google Analytics, Firebase, a Google Translate API, Auth0, React. Eles são o caminho sem atrito, e para a maioria das equipes essa é uma decisão razoável. A contrapartida é que cada um coloca uma parte da sua pilha atrás de um fornecedor que você não pode ler, não pode auditar e não pode abandonar 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 de código aberto que podíamos hospedar nós mesmos. Onde uma camada não toca o conteúdo da sua reunião, mantemos o pragmatismo e dizemos isso. Aqui está a imagem completa.

A espinha dorsal: o motor é nosso código, não de terceiros

Comece pela camada que mais importa, porque a maior parte da sua reunião flui por ela. O transporte em tempo real e a tradução de voz/chat são executados em mind-sdk + a Mind API — nosso próprio motor, na OVH France. A maneira padrão de construir uma reunião traduzida é acoplar um SaaS em tempo real (LiveKit) a uma API de tradução (DeepL, Google); nós não executamos nenhum dos dois no caminho ao vivo. Nenhum modelo de tradução de terceiros está no loop. (Nós usamos DeepL — mas apenas para documentos soltos no chat, não no caminho ao vivo de voz/chat; veja o mapa de tempo de execução. 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 tempo de execução: o SDK em que sua reunião é executada é de código aberto sob a licença BSD 3-Clause — o cliente mind-sdk é público em gitlab.com/mindlabs/api/sdk, direitos autorais de MindMeeting OÜ, nossa entidade de PI estoniana. Ele se comunica com a Mind API em api.mind.com, que nós mesmos executamos na OVH France.

Isso não é um arranjo de código disponível do tipo "olhe, mas não toque". A 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, enquadrados e transmitidos, e auditar essa integração em relação aos seus próprios requisitos. O motor do lado do servidor com o qual ele fala é nosso — não uma caixa preta de terceiros — e um motor totalmente autohospedável para um locatário que precise dele está em nosso roteiro, não é algo que oferecemos hoje. Atualizaremos este post no momento em que for lançado.

Camada por camada: o padrão vs. o que executamos

Dois fios percorrem essa tabela. Código aberto onde a ferramenta processa seus dados — para que possa ser auditada e, em princípio, autohospedada. Padrões abertos (Postgres, a API S3, OIDC) onde dependemos de infraestrutura — para que nada esteja preso ao preço ou à postura de conformidade de um único fornecedor. O Postgres pode mudar para qualquer host Postgres; o armazenamento pode mudar para qualquer repositório S3; a autenticação federa para o provedor de identidade que você já opera. A última linha se situa em um terceiro eixo: o CRM que contém os registros de clientes é domiciliado na UE (Pipedrive, estoniano) em vez de uma plataforma de vendas dos EUA — não é de código aberto, mas também não está sob jurisdição dos EUA.

Alguns desses pontos merecem uma frase a mais. O PostHog é de código aberto e autohospedável; nós o executamos na nuvem da UE da PostHog e o proxiam em primeira parte através de nossa própria origem, para que os eventos não sejam silenciosamente descartados por bloqueadores de anúncios e não transitem por um domínio de análise de terceiros. A autenticação nunca vai para um SaaS de autenticação de terceiros que ficaria entre você e suas sessões — nós mesmos executamos o fluxo OIDC e federamos à sua identidade Google ou Microsoft existente. E as fontes em cada página são servidas a partir de nosso próprio domínio; o único lugar onde o Google Fonts aparece em nossa base de código é em um script offline de ativos da marca, nunca no aplicativo que seus usuários carregam.

Onde somos pragmáticos — dito em voz alta

Não pretendemos que toda a pilha seja feita à mão ou não seja dos EUA. Não é, e um post que afirmasse o contrário seria contradito por nosso próprio mapa de tempo de execução.

O encanamento — hospedagem e SSR (Vercel), a computação do servidor de reunião (Fly.io), pagamentos (Stripe), e-mail transacional (Resend) — é executado em SaaS domiciliado nos EUA. Stripe e Resend lidam com cobrança e convites e nunca veem o conteúdo da reunião. Vercel e Fly são computação alugada: nosso próprio código é executado neles, e o servidor de reunião na Fly lida com a sessão ao vivo e a transcrição que nosso resumo lê — mas é nosso código nas máquinas deles, não um produto de fornecedor ingerindo sua reunião. Tudo é executado na UE em tempo de execução (o assunto do mapa de tempo de execução).

Essa é uma troca deliberada e limitada: possuir e abrir o código do plano de dados; usar o melhor SaaS disponível para o plano de controle. Nomeá-lo é o ponto — "soberania" significa pouco se as exceções não estiverem na 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 o conteúdo derivado da reunião. As etapas de modelo de linguagem que são executadas após a chamada — o AI digest (tópicos, decisões, itens de ação), o post-meeting summary, e o AI note-editor — ficam todas em processadores da UE. O resumo e as ações generativas do editor são executados em Mistral hospedado na UE com zero retenção de dados (alcançado através do AI Gateway da Vercel, fixado no provedor Mistral). O sumário e a ação de traduzir do editor são executados em nosso próprio motor europeu na OVH — o mesmo por trás da voz e do chat ao vivo. Voz, chat, notas e documentos em tempo real nunca chegaram perto de um LLM de propósito geral em primeiro lugar.

O único modelo dos EUA ainda no loop avalia nosso benchmark de tradução público — pontuando traduções automáticas de sentenças de referência fixas do FLORES-200, nunca a reunião de ninguém.

Ainda estamos indo mais longe nas etapas da UE-Mistral: uma opcão de exclusão controlada pelo proprietário para desligar o resumo inteiramente, e um modelo de sumarização de pesos abertos e autohospedado na OVH (classe Kimi) para substituir o Mistral externo. O ponto do caminho de pesos abertos não é de qual laboratório treinou os pesos — é que pesos abertos podem ser executados em infraestrutura que controlamos, o que o mantém no mesmo eixo aberto e autohospedável que o resto do plano de dados. Ambos estão no roteiro, não lançados; atualizaremos este post quando eles chegarem.

Por que isso importa além de nós

Isso não é engenharia por si só. A razão para construir uma pilha dessa forma aparece do seu lado do contrato:

1. Auditável. O SDK em que sua reunião é executada é um código de código aberto que sua equipe de segurança pode ler, e o motor por trás dele é nosso — não uma caixa preta de terceiros.
2. Portátil. Padrões abertos em todas as camadas de dados — Postgres, S3, OIDC — significam que não há bloqueio proprietário. O que pode ser movido não está vinculado a um único fornecedor.
3. Autohospedável. As camadas de dados de padrão aberto — Postgres, S3, OIDC — já são executadas em infraestrutura que você controla; um motor de tradução totalmente autohospedável está no roteiro para o locatário que precisar dele.

Esta é a imagem em 2026-06-07. Vamos atualizá-la quando a pilha mudar — uma troca de fornecedor, uma camada reconstruída, o modelo de resumo substituído. A configuração atual é verificável em nosso vercel.json aberto, em nosso nuxt.config.ts, e no repositório mind-sdk BSD-3-Clause vinculado acima.

Se uma camada aqui parecer errada, ou se sua revisão de segurança precisar de uma resposta que este mapa não fornece, escreva para nós. Preferimos corrigir um detalhe ausente a fazer com que você o encontre em uma auditoria de código.

Fontes: o repositório mind-sdk (BSD-3-Clause), FLORES-200; fatos da pilha verificados em relação à configuração implantada (vercel.json, nuxt.config.ts) e ao código enviado, verificado em agosto de 2026.