第三部分 — 信任层的九项原则

原则九 — 一个产品，多处安家

有一个让临床软件建造者瘫痪的问题：产品该做 SaaS 还是 本地部署？这场争论通常被框成一道单选题，这是个错误。在 受监管市场里，正确的答案是：产品是同一个东西，它住在 好几种不同的家里——因为决定计算可以在哪里运行的，是 客户的数据治理，而不是你的架构偏好。

大型药企不会把患者数据送进一家年轻厂商的云。不是做不到， 而是他们自己对研究者和监管者的承诺，让"数据放在哪里"成为 一个由风险委员会、而非采购部门回答的问题。与此同时，一家 小型 biotech 可能恰恰偏好 SaaS，因为它没有任何基础设施 可以托管东西。而教学受众两个都不想要；它想要的是一个用 合成数据、五分钟就能跑起来的演示。

这不是三个产品。这是同一个内核的三个家——前提是这个内核 在建造时做好了正确的分离。

让这一切成为可能的分离

• 内核高于一切。 引擎、比对机器、验证包：纯粹、与环境 无关、版本锁定。内核不知道是谁在调用它。
• 身份是可插拔的。 认证是一个接口，不是一个假设。同一 个产品，在这次部署里讲厂商门户的令牌，在那次部署里讲 现成的 OIDC 提供方，在第三次部署里用合成数据的演示模式。 一个焊死在某一家客户登录系统上的产品不是产品，是一个 租户。
• 数据原地不动。 流水线走到数据那里去，而不是反过来。 在客户的环境内部执行——他们的 VPC、他们的网络共享、 他们的受管区域——不是一种降级模式；它是旗舰模式，而且 必须从第一天起就按此设计，而不是事后补装。
• 每个家产出同样的证据。 无论一次渲染发生在公开演示里 还是严密封锁的客户飞地里，它产出的都是同样的清单、同样 的地址、同样的审计图。即使数据不可携带，信任也是可携带的。

参考部署

这个设计里藏着一项安静的战略资产：参考部署——一个 真实的、生产级的实例，运行在一个有真实治理、真实用户和 真实后果的组织内部。它不是产品本身，也绝不能让任何东西 泄漏进产品的代码或数据。它泄漏出来的是可信度：它证明 内核经得住与一个真实的受监管环境的碰撞，而再多的演示 打磨也替代不了这一点。没有参考部署的厂商，描述的是一种 理论；有参考部署的厂商，描述的是一个普通的周二。

这里的纪律是让流动方向保持诚实：模式、加固手段和教训， 从参考部署流向产品；数据、凭据和雇主的资产，永不反向。 这条边界是原则七中的一条红线，也正是它，让你能不带 星号地说"经过生产实战检验"。

为什么这胜过"SaaS 优先"

在数据很随意的市场里，SaaS 优先是个不错的赌注。在受监管 的临床市场里，它先放弃了预算最大、合同最长的客户，然后 才发现剩下的那个细分——愿意上传敏感数据的小团队——很小， 而且变小的原因不会消失。一个内核、多处安家，建起来慢一个 季度，但耐用性以十年计。

检验。 问一问："如果我们最好的潜在客户下个月要求 产品完全在他们的网络内部运行，那会是一次部署演练，还是 一次重写？" 如果诚实的答案是"重写"，那这个产品的家 是厂商的云，而客户只是在里面租了个房间。