Sovereignty

一场 InterMIND 会议实际运行在何处

逐一梳理哪些外部服务会接触您的会议、它们在何处运行、以及哪些数据会流经其中。包括目前唯一一条在供应商层面仍会离开欧盟的路径——以及我们正在如何处理。

The Mind.com Team

一场 InterMIND 会议实际运行在何处

一场 InterMIND 会议实际运行在何处

每一场严肃的企业采购对话最终都会绕回到同一个问题:"这些数据会去哪里?" DPO 想要一份子处理者清单。CIO 想知道哪些供应商注册在美国。法务想要一张带箭头的示意图。

与其分批通过邮件零散地告诉您,不如让您一次看到全貌。所以这里就是一场会议的数据路径——它所接触的每一项外部服务、各自在何处运行、以及哪些数据流经其中。已在 2026-05-28 对照实际部署配置进行核验。

其中有一条路径,供应商注册地目前仍在美国,我们也直说。其余部分在运行时均位于欧盟。


"在何处运行"究竟意味着什么

在主权相关讨论中,有两件事常被混为一谈,但它们并不是同一回事:

  1. **运行时 / 数据路径。**您会议的字节在请求过程中被实际处理的物理位置。这才是数据驻留法规和大多数 DPA 真正关心的对象。
  2. **供应商公司注册地。**该 SaaS 供应商的法律注册地。这是 CLOUD Act 讨论关心的对象——即美国理论上可以对供应商母公司施加的强制力,无论实际工作负载在哪里运行。

几乎所有"这是欧盟的吗?"的问题,其实都是上述两者之一,只是问得不够精确。下文中我们对每一家供应商分别作答。


一场会议的数据路径

让我们追踪一次通话,从加入会议到事后跟进邮件:

  1. 浏览器打开会议页面。 SSR 在 Vercel 上运行,固定于 fra1(法兰克福)。所有请求/响应数据——会话 cookie、API 负载、服务端渲染的 HTML——在运行时均于欧盟内处理。
  2. **WebSocket 连接到我们位于巴黎(cdg)的会议服务器。**会议编排、在线状态、信令——全部在欧盟。
  3. **语音识别在发言者的浏览器中运行。**本地完成。在转写结果被送去翻译之前,从不离开设备。(我们在 翻译流水线内幕 中介绍了原因。)
  4. **语音和聊天翻译进入我们部署在 OVH 法国的自有引擎。**这就是 mind-sdk-web——我们的代码,我们的主机,位于法国。链路中没有任何第三方模型。亚秒级预算、按语言划分的 WebSocket 连接池、每一跳都在欧盟。
  5. 拖入聊天的文档(PDF、DOCX、PPTX、XLSX)从巴黎的 ws-server 服务端发送至位于科隆的 DeepL。德国公司,德国境内处理。语音和聊天不会接触 DeepL。
  6. 应用数据——用户、团队、消息、会议元数据——存放于 AWS 法兰克福(eu-central-1)上的 Neon Postgres。快照在同一区域。
  7. 录像、附件、导出文件存放于 Tigris,基于 S3 兼容的对象存储,运行在 Fly 上。边缘复制;对于需要更严格固定区域的租户,存储桶可配置为多区域欧盟。
  8. 错误与性能追踪发送至 Sentry 的欧盟实例(de.sentry.io)。美国组织已于五月停用。
  9. 产品分析发送至 PostHog EU(eu.i.posthog.com)。
  10. 事务性邮件(魔法链接、邀请、收据)通过 Resendeu-west-1(爱尔兰)发出。

以上所有内容在运行时均位于欧盟。翻译引擎——您大部分数据真正流经的部分——也是我们自己的代码,这意味着对于有需要的客户,引擎本身可以被审计或自行托管。


供应商一览

供应商用途运行位置
OVH(mind-sdk-web)语音 + 聊天翻译引擎法国
Fly.io会议 WebSocket 编排巴黎(cdg)
Vercel(Nuxt + Nitro API)应用外壳、服务端 API、SSR法兰克福(fra1)
Neon应用 PostgresAWS 法兰克福(eu-central-1)
Tigris对象存储(录像、附件)边缘复制;可固定于欧盟
DeepL文档翻译(PDF/DOCX/PPTX/XLSX)科隆
Sentry错误追踪de.sentry.io(欧盟)
PostHog产品分析eu.i.posthog.com
Resend事务性邮件爱尔兰(eu-west-1)
Stripe支付爱尔兰(Stripe Payments Europe Ltd.),面向欧盟客户

按数据量计算,最重的两条数据流——通过我们在 OVH 上的自有引擎进行的语音/聊天翻译,以及通过 DeepL 进行的文档翻译——其母公司也恰好都位于欧盟。这覆盖了会议内容的大部分。完整的子处理者清单及公司注册地详情,按惯例随 DPA 一并提供;上表呈现的是运行时视角,而这正是大多数数据驻留条款真正关心的内容。


目前唯一的空白,直说

通话结束后,我们会生成一份会后 AI digest——议题、决策、行动项、待解决问题。生成 digest 的模型通过 Vercel 的 AI Gateway(一个欧盟区域的代理)接入,但底层模型是 Google Gemini 2.5 Flash,并以 Anthropic Claude Sonnet 作为回退——两者均为美国注册的供应商。

实时语音、实时聊天和文档翻译不会经过这条路径。digest 是一个独立的会后步骤,基于我们已经生成的转写文本,在其之上写出摘要。

我们正以两种方式来填补这一空白:

  1. **由所有者控制的退出开关,即将推出。**工作区所有者将能够完全禁用 AI digest 流水线,届时不会生成任何会后摘要,转写文本就停留在它原本所在的位置——欧盟内。对新租户默认关闭;现有租户会收到通知,如愿意可继续保持启用。
  2. **自托管的欧盟摘要模型。**我们正在 OVH 上部署一个开源权重模型(Kimi 级别),用于摘要这类不需要前沿级推理能力的任务。一旦它成为 digest 的后端,这一权衡就不复存在——同一条流水线将不再涉及任何美国注册的供应商。

如果 digest 是您的采购评估中"这套方案可行"与"不可行"之间的分水岭,请告知我们——我们会据此调整优先级。


这对您的 DPA 意味着什么

对于大多数欧盟买家——德国 Mittelstand、运行标准 GDPR DPA 的受监管行业——上述图景直接回答了数据驻留问题:您的会议在运行时的每一跳都位于欧盟。供应商注册地按惯例在子处理者清单中披露;没有任何意外。

对于法国 souveraineté numérique 和 SecNumCloud 级别的采购,供应商公司注册地本身就是评估标准的一部分,而不仅仅是运行时位置。那是另一种对话——一种替代性的部署拓扑,使每一个组件都处于欧洲司法管辖的供应商之下。我们不会默认运行该拓扑;但对于确有此类需求并且合同足以支撑该建设的租户,我们会为其搭建。

对于美国本土以及大多数亚太地区买家而言,情况通常正好相反——他们希望从自己所在区域获得低延迟,这是另一个问题。今天我们以单区域方式运行于 fra1。如果您的流量足以支撑美国边缘节点,我们会与您一起规划。


这篇文章对我们的约束

这是 2026-05-28 时的图景。当技术栈发生变化时——供应商更换、区域迁移、新增外部服务——我们会更新。当前配置可以在我们开放的 vercel.json、运行于 OVH 法国的 mind-sdk-web 引擎,以及每个供应商各自的控制台中得到核验。

如果这里有什么看起来不对,或者您的 DPO 需要这份图景没有给出的答案,请联系我们。我们宁愿补上一个遗漏的细节,也不愿让您在合同评审中才发现它。