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

原则七 — 红线与人在回路

受监管领域的自动化有一条不可谈判的设计事实：有些决定属于人，而系统必须知道是哪些。 过度自动化的失效模式并不戏剧化；它是判断力缓慢地向默认值迁移，直到有一天，没有人说得清那件人人都以为"有人定了"的事，到底是谁定的。

这门纪律有两半：任何自动化都不得越过的红线，以及在正确时刻把人请回来的回路。

红线要少、要绝对、要写下来

红线是一条在 deadline 压力下也不容例外的规则——因为红线一旦有例外流程，它就成了一条穿着戏服的指导原则。在临床流水线里，它们通常长这样：

患者数据与研究数据绝不跨越不该跨越的边界。 为某个目的、在某种治理制度下采集的数据，绝不泄漏到别处—— 不进演示环境，不进训练集，不进厂商的云。系统用结构来执行这一点(独立环境、合成演示数据)，而不是靠制度，因为结构能挺过周五傍晚。
盲态保持盲态。 凡是试验完整性取决于"谁知道什么"的地方，系统就在访问路径上强制执行盲态，任何破盲都是一个挂名记录的事件——绝不是悄悄翻转一个配置开关。
这条线没法靠嘴皮子绕过去。 未通过的核验门、缺失的签名、未经批准的草稿：这些都会停掉渲染。升级通道是存在的，但它是一项由有权限的人做出的、明确的、签字的、记录在案的行为——而不是一个覆盖参数。

对红线的检验是组织性的，不是技术性的：当一位资深人士在真实压力下要求破例时，会发生什么？在健康的系统里，答案是 "这是偏差申请表，以及它会如何记录谁批准了什么"。在不健康的系统里，某个有 root 权限的人"修好了它"，而整张图学会了视而不见。

在红线之间，自动化应该激进——但它必须认得自己能力的边界。实践中行之有效的模式不是"事事由人批准"(那只会产生橡皮图章，一种监督的幻觉)，而是结构化路由：系统把每一单元工作归类为"在其确定性能力之内"或"不在"，而那些例外会变成一个队列，里面是一个个具体的、框架清晰的问题。

一份规则引擎无法完整表达的规格，不会变成一个无声的默认值；它会变成一条复核事项，准确写明哪条推导定义不足。一个比对失败的数字，不会变成一条警告；它会变成一条带有双方谱系的不匹配记录。一份 AI 生成的草稿，不会变成输出；它会一直保持草稿标签，直到某个具名的人接受它。

做得好时，这个回路是符合人体工学的：人把注意力花在真正的判断题上——这个分析人群的定义适合这项试验吗？——而绝不花在誊抄、排版或对账上。系统对自己做不到的事保持诚实，而这恰恰让它其余的产出值得信赖。

归根结底，问责才是要点。每个受监管的系统都必须能回答 "这是谁决定的？"——而"流水线"不算答案。流水线的职责，是确保这个问题永远有一个名字、一个时刻和一份记录。

检验。 对任何一个自动化步骤发问："当它不确定时，物理上会发生什么？" 如果不确定变成了输出里的一个默认值，那系统正在悄悄决定一些从没人让它决定的事。如果它变成一条被路由的问题、且解决方案上署着人名，那这个回路是真的。