为医疗保健构建隐私优先的 AI：真正打动我的是什么

来自我们一位早期试点医生的笔记，经其许可后编辑发表。——ActiveScribe 团队

当第一批 AI 医疗助手厂商开始出现在医学会议上时，我做了大多数同行都会做的事：礼貌地点头，拿走宣传册，然后在停车场把它扔掉。我在安大略省做家庭医生已经十一年了。我亲眼看着 OHIP 的传真机熬过了三轮电子病历系统的迁移。我绝不会把患者一次心理健康危机的录音，交给一家硅谷初创公司，更何况他们的隐私页面上"加密"这个词都打错了。

让我改变想法的不是销售话术，而是一份清单。

某个周末，我坐下来，用最直白的语言写下了在让任何工具收听我的就诊之前需要得到答案的问题。不是市场营销的问题（"它安全吗？"），而是那些答案要么是具体的技术事实、要么是回避手段的问题。我想在这里逐一讲讲这份清单，以及我和构建 ActiveScribe 的团队一起核对它时学到的东西。

音频究竟流向哪里？

这是第一个问题，大多数厂商在这一刻都会变得明显不自在。ActiveScribe 给出的诚实回答是：当我在浏览器里按下录音键时，音频以 48 kHz 采集，在我的设备上下采样到 16 kHz，然后通过加密的 WebSocket 流式传输到他们位于 AWS ca-central-1（蒙特利尔）的后端。从那里，音频被交给 Deepgram（他们的语音转文字供应商）进行转录，生成的文本随后送入 AWS Bedrock 上运行的 Anthropic Claude 模型，由它来生成笔记。

对我来说，重要的并不是他们用了云服务——而是他们能告诉我用的是哪一家云、在哪一个区域、由哪家公司运营、负责哪一步。如果一家厂商连在餐巾纸上画出这张架构图都做不到，他们就不应该接触患者数据。

什么会被保留，什么会被丢弃？

这是 ActiveScribe 回答了我都不知道自己应该问的问题的地方。他们与 Deepgram 的合约里写明了一条零数据留存条款：我发送给他们的音频不会被存储、不会被用来训练任何人的模型，也不会比生成转录的那一次 API 调用活得更久。AWS Bedrock 那一侧也是如此——Bedrock 上的 Anthropic 模型不会用推理数据来训练。

至于音频文件本身，在 ActiveScribe 那一侧，它在离开我的浏览器之前就已经在我设备上用 AES-256 加密好了，密钥则用 AWS 中他们的 KMS 密钥进行封装。转录稿和笔记存入他们的数据库时使用的是字段级加密——不是行级、不是表级，而是字段级，对每一列包含患者信息的字段都进行加密。

我问他们，如果他们公司的某位开发者执行了 SELECT * FROM encounters，会发生什么。回答是"他得到的是密文"。这才是正确的回答。

我真的能看到谁动过我的数据吗？

审计日志是把认真的厂商和其他厂商区分开来的考验。对一次就诊的每一个操作——查看、编辑、导出、删除——都会记录用户 ID、时间戳和操作类型。作为临床医生，我可以为任何一份笔记调出这段历史。作为监管机构，原则上我也可以提同样的问题，得到同样的答案。

我在意的不是审计日志写在了宣传册里。我在意的是我自己能看到它。

"不训练"承诺

现在每一家 AI 厂商都会承诺不会用你的数据训练模型。这种承诺的价值，恰恰等于它背后那份合同的价值。ActiveScribe 的承诺通过两种方式得到落实：与 Deepgram 签订的 BAA（零留存、不训练），以及对 Bedrock 模型的 BAA 资格调用（不在推理数据上训练）。在他们的架构中，我的患者音频不可能进入任何人的下一代模型。这不是市场营销宣称——这是合约约定，我在注册之前就要求查看了相关条款。

我至今还不懂的部分（这也没关系）

我是医生，不是安全工程师。这套技术栈里有些部分我永远不会完全理解——KMS 信封加密、Redis 流消费者、IAM 认证的数据库代理。我不需要理解它们。我需要的是构建这个工具的团队能够把它们解释给那些真正懂的人听，并且能拿出真实的配置文件，让我可以请第三方去审计。

构建 ActiveScribe 的团队通过了 ISO/IEC 27001:2022 认证，这意味着独立审计师已经做过这件事了。这并不能让这款工具变得完美，但它意味着这不是某个拿着信用卡和 Vercel 账号就开干的人。

我会对另一位医生说什么

不要问厂商"你们安全吗"。问他们音频去了哪里、什么会被保留、谁有权限访问、出了问题你怎么知道。答案应该具体，并且应该能写在一张纸上。如果一家厂商无法准确告诉你哪些子处理方会接触到你患者的声音，那就走人。

没人付钱让我写这篇文章。我是一个省份的家庭医生，我所在省份的监管学院如果发现我在这件事上出了差错，是可以吊销我执照的。我选择了那家工程师愿意坐下来开会、回答这些枯燥问题的工具。