第 20 章 · 上线前的那道门
效果好,不等于能上线
有个项目,PoC 阶段所有指标都漂亮,业务方拍板要上线。工程师觉得「效果都达标了,部署一下就完事」,当天就把它接进了生产客服系统。
第三天出事了:一个客户问了句刁钻的话,AI 把另一个客户的订单信息答了出去——权限没隔离干净。更糟的是,团队想查「到底怎么泄的」,发现没有日志;想紧急关掉,发现没有开关,只能连夜把整个服务下线,客服瘫了半天。
效果达标,是「这东西有用」;能上线,是「这东西用起来不会闯祸」。这是两道完全不同的关。 前一道靠第 16 章的评估过,后一道,靠这一章要讲的上线门禁。
FDE 戴上监控运维官这顶帽子,守的就是这道门。门禁的原则只有一条:逐项打勾,缺一项都不上线。 它不是官僚流程,是拦住「效果好但会闯祸」的东西冲进生产的最后一道拦河坝。完整清单见附录 F,这一章讲清最要命的五扇门。
五扇必须关好的门
上线门禁项目不少,但最容易出人命的是这五扇。
第一扇:权限——谁能看什么、做什么。 开头那个泄露事故,就是这扇门没关。必须确认:不同用户/租户之间数据隔离,AI 不会把 A 的信息答给 B;每个工具的调用权限最小化,该只读的绝不给写权限。
📎 技术深读:沙箱隔离、工具安全执行的工程实现,见 Harness Agent Book · 第 27 章;多租户数据隔离见 第 28 章。
第二扇:数据脱敏——敏感信息不裸奔。 凡是碰到个人敏感信息(PII)——手机号、身份证、账号——要么不落地,要么脱敏。这不只是技术要求,是法律红线。第 19 章那个内部数据场景,这扇门是重中之重。
第三扇:审计日志——出了事查得到。 「谁在什么时候让 AI 做了什么、AI 调了哪些工具、结果如何、有没有人审过」——全都要有日志。开头那个事故查不出原因,就是缺了这扇门。没有审计日志的 AI 系统,等于开着一辆没有行车记录仪的车上高速。
第四扇:人审机制——危险动作有人兜底。 第 3、7 章反复讲的人审门,到上线这一刻要落成真机制,不是写在文档里的口号。对外发送、涉及金额、删除数据——这些动作必须真的卡着人工确认,而且要有日志证明「确实有人点过头」。
第五扇:回滚方案——错了能立刻收手。 开头那个「只能连夜下线」的窘境,就是没有回滚设计。上线前必须写死:什么信号出现就回滚、回滚做什么动作、谁有权按、按了通知谁。理想的回滚不是「拔电」,而是「降级」——比如 AI 出问题就自动切回纯人工,业务不中断。
一张门禁评审表
上线前开一场门禁评审会(第 12 章的关口会),拿这张表逐项过,当场判「上」或「不上」。
| 门 | 检查项 | 通过? | 没过怎么办 |
|---|---|---|---|
| 权限 | 租户/用户数据隔离、工具最小权限 | ☐ | 补隔离,重测 |
| 脱敏 | PII 不落地或已脱敏 | ☐ | 加脱敏,法务确认 |
| 审计 | 全链路日志(谁/何时/做了什么/人审) | ☐ | 补日志字段 |
| 人审 | 高风险动作真卡人工确认 | ☐ | 落成机制,非文档 |
| 回滚 | 触发条件/动作/负责人/降级策略齐全 | ☐ | 写死回滚预案 |
第 18 章那个案例,门禁评审时就有两项没过——审计日志字段不全、回滚触发条件没写死——没过就是没过,补齐才上,绝不「先上了再说」。这张表最大的价值,是把「要不要上线」从一个拍脑袋的决定,变成一个有据可查、责任清晰的评审结论。它同时也是给采购和安全团队看的合规证明。
企业里还可以把门禁映射成治理责任：
| 治理项 | 本书对应动作 | 责任人 | 证据 |
|---|---|---|---|
| 风险识别 | 场景卡风险栏、高风险样本 | FDE + AIBP + 安全 | 风险清单 |
| 风险度量 | Golden Dataset、类别级指标 | FDE + AIBP | 跑分报告 |
| 风险控制 | 权限、人审、脱敏、输出校验 | 技术负责人 + 安全 | 配置和评审记录 |
| 风险恢复 | 回滚、降级、事故通知 | 运维负责人 | Runbook 和演练记录 |
| 治理责任 | RACI、上线签字 | Sponsor + AIBP | 门禁评审结论 |
还要特别关注几类 LLM 应用常见风险：
| 风险 | 在项目里的表现 | 门禁动作 |
|---|---|---|
| Prompt Injection | 用户输入诱导 AI 忽略规则或泄露系统提示 | 输入隔离、工具调用前校验 |
| Sensitive Information Disclosure | 把客户隐私、内部资料或 A 租户数据答给 B | 脱敏、租户隔离、输出检查 |
| Insecure Output Handling | AI 输出直接写库、发客户、触发外部动作 | 高风险动作人审 |
| Excessive Agency | 工具给太多、权限过大，AI 能做不该做的事 | 最小授权、工具白名单 |
| Model Denial of Service | 循环过长、调用暴涨、成本失控 | 步数上限、成本告警、超时 |
门禁不是一次性的
一个提醒:门禁不是「上线那天过一次就完」。上线后,权限会变、数据会增、新功能会加——每次重大变更,都要回过头再走一遍相关的门。把门禁清单当成一个常驻的检查表,而不是上线仪式上用一次的道具。这也是从「上线」平滑过渡到「运营」(第 21 章)的关键。
上线前最好做一次回滚演练。不要只在文档里写「必要时降级」，而是现场按一遍：谁有权限关、关掉后用户看到什么、人工流程怎么接上、通知发给谁、恢复上线要满足什么条件。演练过的回滚，才是能用的回滚。
常见坑
- 效果达标就直接上。 把「有用」当成「能上线」,权限/日志/回滚全没做,第一次意外就是事故。
- 人审只写在文档里。 说「高风险要人审」,却没落成真机制、没有确认日志,等于没有。
- 没有回滚,只能拔电。 出事只能整个下线,业务大面积中断。要设计降级而非硬关。
- 门禁走个形式。 明明有项没过,为了赶进度「先上再补」——补的那天往往就是出事那天。
- 上线后就不再看门禁。 把它当一次性仪式,后续变更不复查,旧门重新裂开。
本章产出
往交付包里放一份「上线门禁评审表 + 回滚预案」:
用 附录 F 的清单,为你的项目逐项打勾,把没过的项列成待办;并写死一份回滚预案(触发条件/回滚动作/负责人/降级策略)。这份评审表,是你敢对业务方说「这东西可以真上线了」的底气,也是出事时能快速止损的依据。
成熟度自检
- [ ] 我能用门禁清单逐项评审,守住权限/脱敏/审计/人审/回滚五扇门(→ L3 迈向 L4)
- [ ] 我能写死可执行的回滚与降级预案,并在每次变更后复查门禁(→ 巩固 L4)