Do que é feita uma reunião no InterMIND

Quase todo produto é construído sobre a mesma stack padrão: os grandes SaaS proprietários que todo mundo escolhe de primeira. É o caminho sem atrito. Em cada camada onde os dados da sua reunião realmente ficam, escolhemos outro: código nosso ou open source que podemos hospedar por conta própria.

Este texto é o complemento de Onde uma reunião do InterMIND realmente roda, que mapeou a geografia: onde cada serviço é executado e quais dados passam por ele. Aqui respondemos à pergunta que uma equipe de segurança faz em seguida: do que isso é feito — e podemos ler, auditar e substituir?

Não onde roda, mas do que é feito, camada por camada.

Os padrões e o que eles custam

Todo produto é uma pilha de escolhas. Na maioria dos produtos, a maior parte dessas escolhas é feita por padrão: Google Analytics, Firebase, a API do Google Translate, Auth0, React. É o caminho sem atrito e, para a maioria das equipes, uma decisão razoável. O custo é que cada uma dessas escolhas coloca uma parte da sua stack atrás de um fornecedor que você não pode ler, não pode auditar e não pode abandonar sem reescrever tudo.

Fizemos uma escolha diferente em cada camada onde os dados da sua reunião realmente ficam: código nosso ou software open source que podemos hospedar por conta própria. Onde uma camada não toca o conteúdo da sua reunião, somos pragmáticos e dizemos isso. Aqui está o quadro completo.

O núcleo: o motor é código nosso, não de terceiros

Comece pela camada mais importante, porque é por ela que passa a maior parte da sua reunião. O transporte em tempo real e a tradução de voz e chat rodam em mind-sdk + a Mind API — nosso próprio motor, na OVH França. O jeito comum de montar uma reunião traduzida é acoplar um SaaS de tempo real (LiveKit) a uma API de tradução (DeepL, Google); não executamos nenhum dos dois no caminho ao vivo. Nenhum modelo de tradução de terceiros participa do processo. (Usamos o DeepL, sim, mas só para documentos enviados ao chat, não no caminho de voz e chat ao vivo; veja o mapa de execução. Detalhamos a mecânica dos pipelines em Por dentro dos quatro pipelines de tradução.)

Eis o que não aparece no mapa de execução: o SDK sobre o 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, com copyright da MindMeeting OÜ, nossa entidade de propriedade intelectual na Estônia. Ele se comunica com a Mind API em api.mind.com, que operamos nós mesmos na OVH França.

Não é um arranjo de código "pode olhar, mas não pode tocar". 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 seu texto são capturados, estruturados em frames e transmitidos, e auditar essa integração conforme seus próprios requisitos. O motor do lado do servidor com o qual ele se comunica é nosso, não uma caixa-preta de terceiros. Um motor totalmente self-hosted para o tenant que precisar está no nosso roadmap, não é algo que oferecemos hoje. Atualizaremos este texto assim que estiver disponível.

Camada por camada: o padrão do mercado vs. o que rodamos

Dois fios condutores atravessam essa tabela. Open source onde a ferramenta processa seus dados, para que possa ser auditada e, em princípio, hospedada por conta própria. 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. O Postgres pode ir para qualquer host de Postgres; o armazenamento pode ir para qualquer storage S3; a autenticação se federa ao provedor de identidade que você já usa. A última linha está em um terceiro eixo: o CRM que guarda os registros de clientes tem sede na UE (Pipedrive, estoniano) em vez de ser uma plataforma de vendas dos EUA — não é open source, mas também não está sob jurisdição dos EUA.

Alguns desses itens merecem mais uma frase. O PostHog é open source e pode ser hospedado por conta própria; nós o executamos na cloud da PostHog na UE e o encaminhamos via proxy first-party pela nossa própria origem, para que os eventos não sejam descartados silenciosamente por bloqueadores de anúncios e não passem por um domínio de analytics 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 o federamos à sua identidade existente no Google ou na Microsoft. E as fontes de todas as páginas são servidas do nosso próprio domínio; o único lugar em que o Google Fonts aparece no nosso código é um script offline de ativos de marca, nunca o app que seus usuários carregam.

Onde somos pragmáticos — dito com todas as letras

Não fingimos que a stack inteira é feita à mão ou fora dos EUA. Não é, e um texto que afirmasse o contrário seria desmentido pelo nosso próprio mapa de execução.

A infraestrutura de apoio — hospedagem e SSR (Vercel), a computação do servidor de reuniões (Fly.io), pagamentos (Stripe), e-mail transacional (Resend) — roda em SaaS com sede nos EUA. Stripe e Resend cuidam de 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 roda neles, e o servidor de reuniões na Fly de fato lida com a sessão ao vivo e com a transcrição que nosso digest lê — mas é o nosso código nas máquinas deles, não um produto de fornecedor ingerindo a sua reunião. Tudo isso é executado na UE em tempo de execução (o tema de o mapa de execução).

É uma troca deliberada e delimitada: código próprio e open source no plano de dados; o melhor SaaS disponível no plano de controle. Nomear isso é o ponto — "soberania" significa pouco se as exceções não estão na mesa ao lado das vitórias.

As etapas de IA e o plano que foi entregue

As etapas com modelo de linguagem — o AI digest (tópicos, decisões, action items), os resumos de documentos, as ações generativas do editor de notas com IA, o Ask AI e a Mia — rodam no gateway de IA que sua organização seleciona: Azure OpenAI na EU Data Zone por padrão, Vertex AI no endpoint multirregional da UE ou Amazon Bedrock em Frankfurt por escolha, cada um no nosso próprio tenant, com zero retenção de dados e sem treinamento com conteúdo de clientes — ou seu próprio endpoint compatível com OpenAI, que mantém o modelo em uma infraestrutura que você controla. O resumo pós-reunião e a ação traduzir do editor passam pelo trato de tradução, não pelo modelo de linguagem. Voz em tempo real, chat, notas e documentos nunca passaram perto de um LLM de uso geral.

Esse é o formato honesto desta camada: os modelos são proprietários e seus fornecedores são empresas dos EUA que operam regiões na UE — a mesma troca da infraestrutura de apoio acima, dita ao lado dela em vez de escondida. O que foi entregue no lugar de um modelo próprio self-hosted é a escolha: uma organização pode desligar a IA por completo (transcrição e tradução continuam funcionando) e pode apontar cada recurso de IA para o seu próprio endpoint — vLLM no seu próprio data center, uma implantação no seu próprio tenant —, o que coloca esta camada no mesmo eixo aberto e self-hosted do restante do plano de dados. Nosso benchmark de tradução público é avaliado por um LLM juiz (Gemini, com Claude como fallback) em frases de referência fixas do FLORES-200 — nunca na reunião de ninguém.

Por que isso importa além de nós

Isso não é engenharia por engenharia. O motivo para construir uma stack assim aparece do seu lado do contrato:

1. Auditável. O SDK sobre o qual sua reunião roda é código open source 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á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 fica preso a um único fornecedor.
3. Self-hostable. As camadas de dados em padrões abertos — Postgres, S3, OIDC — já rodam em infraestrutura que você controla; um motor de tradução totalmente self-hosted está no roadmap para o tenant que precisar.

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 no nosso vercel.json aberto, no nosso nuxt.config.ts e no repositório mind-sdk BSD-3-Clause linkado acima.

Se alguma camada aqui parecer errada, ou se a sua revisão de segurança precisar de uma resposta que este mapa não dá, escreva para nós. Preferimos corrigir um detalhe ausente a ver você descobri-lo em uma auditoria de código.

Fontes: o repositório mind-sdk (BSD-3-Clause), FLORES-200; fatos da stack verificados na configuração implantada (vercel.json, nuxt.config.ts) e no código entregue, conferidos em agosto de 2026.