一场 InterMIND 会议的构建基础

几乎每个产品都构建于相同的默认技术栈——大家都会选择的那些大型专有 SaaS 默认方案。它们是阻力最小的路径。在您的会议数据实际驻留的每一层，我们做出了不同的选择：使用我们自己的代码，或是我们可以自行托管的开源软件。

这是 一场 InterMIND 会议究竟在哪里运行 的伴生文档，那篇文章绘制了地理分布——每个服务在哪里执行，以及哪些数据会通过它。这篇文章回答了安全团队接下来的问题：这个东西是由什么构建的——我们能否阅读它、审计它并替换它？

不是关于它在哪里运行——而是关于它由什么构成，逐层剖析。

默认方案及其代价

每个产品都是一系列技术选型的组合。对于大多数产品而言，大部分选型是默认做出的：Google Analytics、Firebase、Google Translate API、Auth0、React。它们是阻力最小的路径，对大多数团队来说这也是合理的选择。代价在于，每一个默认选择都会将您技术栈的一部分置于某个供应商之后，您无法阅读它、无法审计它，不重写也无法离开它。

在您的会议数据实际驻留的每一层，我们做出了不同的选择：我们自己的代码，或是我们可以自行托管的开源软件。 对于不接触您会议内容的层，我们保持务实态度并予以说明。以下是全貌。

核心骨干：引擎是我们的代码，而非第三方的

从最重要的一层开始，因为您的大部分会议数据都流经这里。实时传输和语音/聊天翻译都运行在 mind-sdk + Mind API——我们自己的引擎，托管于 OVH France。 构建翻译会议的默认方式是将实时 SaaS（LiveKit）外挂到翻译 API（DeepL、Google）上；我们在实时路径中两者都不使用。没有任何第三方翻译模型参与其中。（我们确实使用了 DeepL——但仅限于拖入聊天的文档，而非实时的语音/聊天路径；请参阅运行时映射图。我们在 深入解析四大翻译管道 中介绍了管道机制。）

这里有一运行时映射图中未提及的部分：您的会议所运行的 SDK 是基于 BSD 3-Clause 许可证的开源软件——mind-sdk 客户端在 gitlab.com/mindlabs/api/sdk 公开，版权归属 MindMeeting OÜ，即我们的爱沙尼亚知识产权实体。它与 api.mind.com 的 Mind API 进行通信，该 API 由我们在 OVH France 上自行运行。

这不是一种“只能看，不能动”的源码可见安排。BSD 3-Clause 是一种宽松的、经 OSI 批准的许可证。您的安全团队可以克隆该 SDK，确切阅读您的音频和文本是如何被捕获、封装和流式传输的，并根据您自身的要求审计该集成。与其通信的服务器端引擎是我们自己的——而不是第三方的黑盒——并且对于需要它的租户，完全可自行托管的引擎已在我们的规划路线图中，但并非我们今天提供的产品。它一发布，我们就会更新这篇文章。

逐层解析：默认方案与我们运行的方案

这张表中有两条主线。在工具处理您数据的地方采用开源软件——因此可以被审计，并且原则上可以自行托管。在我们依赖基础设施的地方采用开放标准（Postgres、S3 API、OIDC）——因此没有任何东西被锁定在某一个供应商的定价或合规姿态上。Postgres 可以迁移至任何 Postgres 主机；存储可以迁移至任何 S3 存储；身份验证可联合至您已经在运行的身份提供商。最后一行位于第三条轴线上：持有客户记录的 CRM 注册于欧盟（Pipedrive，爱沙尼亚公司）而非美国销售平台——它不是开源的，但也不受美国管辖。

其中有几项值得多说一句。PostHog 是开源且可自行托管的；我们在 PostHog 的欧盟云上运行它，并通过我们自己的源站将其代理为第一方流量，这样事件既不会被广告拦截器静默丢弃，也不会经过第三方分析域。身份验证绝不会流向位于您和您的会话之间的第三方身份验证 SaaS——我们自行运行 OIDC 流程，并联合至您现有的 Google 或 Microsoft 身份。每个页面上的字体都从我们自己的域名提供；Google Fonts 在我们代码库中唯一出现的地方是一个离线品牌资产脚本，绝不会出现在您用户加载的应用中。

我们的务实之处——公开说明

我们不假装整个技术栈都是纯手工打造或非美国的。事实并非如此，任何声称相反的文章都会与我们自己的运行时映射图相矛盾。

基础设施——托管和 SSR（Vercel）、会议服务器的计算（Fly.io）、支付（Stripe）、事务性邮件（Resend）——运行在位于美国的 SaaS 上。Stripe 和 Resend 处理账单和邀请，绝不接触会议内容。Vercel 和 Fly 是租用的计算资源：我们自己的代码在上面运行，Fly 上的会议服务器确实处理了实时会话以及我们的摘要所读取的转录文本——但那是我们的代码在他们的机器上运行，而不是供应商产品在摄取您的会议。所有这些在运行时均在欧盟执行（这是运行时映射图的主题）。

这是一个深思熟虑且界限分明的权衡：拥有并开源数据平面；为控制平面使用可用的最佳 SaaS。将其指出来才是关键——如果这些例外情况不能与优势摆在一起公开讨论，那么“主权”就毫无意义。

会后的 AI 步骤及规划

没有任何位于美国的专有模型接触会议派生内容。在通话之后运行的语言模型步骤——AI 摘要（话题、决策、行动项）、会后总结以及 AI 笔记编辑器——均位于欧盟处理器上。摘要和编辑器的生成操作运行在托管于欧盟的 Mistral 上，且零数据保留（通过 Vercel 的 AI Gateway 访问，固定指向 Mistral 供应商）。总结和编辑器的翻译操作运行在我们自己的欧盟引擎上（位于 OVH）——即支撑实时语音和聊天的同一个引擎。实时的语音、聊天、笔记和文档从一开始就从未接触过通用 LLM。

唯一仍在链路中的美国模型用于评判我们公开的翻译基准测试——对固定的 FLORES-200 参考句子进行机器翻译评分，绝不涉及任何人的会议。

我们仍在进一步深化 EU-Mistral 步骤：提供所有者控制的退出选项以完全关闭摘要功能，以及在 OVH 上自托管的开源权重摘要模型（Kimi 级别）以取代外部的 Mistral。采用开源权重路径的意义不在于哪个实验室训练了这些权重——而在于开源权重可以在我们控制的基础设施上运行，这使得它与数据平面的其余部分保持在相同的开放且可自托管的轴线上。这两项都在我们的路线图中，尚未发布；当它们落地时，我们会更新这篇文章。

为什么这超越了对我们自身的意义

这是为了工程而工程。以这种方式构建技术栈的原因会体现在您所签署合同的这一面：

1. 可审计的。 您的会议所运行的 SDK 是您的安全团队可以阅读的开源代码，其背后的引擎是我们自己的——而不是第三方的黑盒。
2. 可移植的。 每个数据层的开放标准——Postgres、S3、OIDC——意味着没有专有锁定。可以移动的内容不会被绑定到单一供应商。
3. 可自托管的。 开放标准的数据层——Postgres、S3、OIDC——已经运行在您控制的基础设施上；对于需要它的租户，完全可自托管的翻译引擎已在路线图中。

这是 2026-06-07 的全貌。当技术栈发生变化时——供应商更换、某层重建、摘要模型替换——我们会更新此文。当前的配置是可验证的，您可以在我们公开的 vercel.json、nuxt.config.ts 以及上面链接的 BSD-3-Clause mind-sdk 代码库中查阅。

如果这里的某一层看起来有问题，或者您的安全审查需要这张映射图未提供的答案，请给我们留言。我们宁愿纠正遗漏的细节，也不愿让您的代码审查发现它。

来源：mind-sdk 代码库（BSD-3-Clause）、FLORES-200；技术栈事实已根据部署的配置（vercel.json、nuxt.config.ts）和已发布的代码进行验证，于 2026 年 8 月核对。