6.4 四十七条要求为什么挡不住私下试用

第四周，订单到上线团队申请读取已经批准的合同范围。中心团队发来五张表，共四十七项要求。八个工作日后，申请仍在安全、数据、平台和法务之间流转。

业务团队没有继续等。他们用一个部门账号把三份脱敏合同放进外部工具，先验证能不能自动整理启动条件。中心团队发现后准备增加第四十八条规定：“禁止未经批准试用。”

我先暂停这项写规则的冲动。一个正常需求如果没有可走通的入口，真实工作不会消失，只会离开公司的视线。

案例说明：本章控制要求、审批天数、客户例外和改进结果均为虚构教学设定。真实企业的隐私、安全、劳动和行业规则必须由有权岗位确认。

四十七条其实不是同一种东西

我让每条要求的提出者回答四个问题：防止什么具体后果，适用于哪些业务，由谁判断，什么时候允许例外。整理后，它们分成了四类。

类别	原有条数	例子	处理方式
公司底线	9	敏感客户资料不得进入未批准服务；对外动作必须有明确授权	所有项目必须遵守，不能由业务自行豁免
已验证标准做法	13	使用独立 AI 身份、保留来源和重要动作、先小范围发布	符合条件的项目直接复用，不重复证明
项目经验或参考	17	某次试点的页面布局、抽样比例、会议节奏	进入案例库，不作为审批条件
重复或无法解释	8	多张表反复询问负责人；“确保结果绝对准确”	合并或删除

“AI 必须安全可靠”不能作为可执行底线。不同人无法用它作出相同决定。我们把它拆成资料边界、禁止动作、暂停条件、必要记录和事故通知，每一项都有检查方法和负责人。

订单到上线团队需要读取的客户、合同和范围已经在商机到回款流程中批准过。平台团队提供同一身份和来源记录，业务负责人确认使用目的，数据负责人确认可见字段。满足标准的申请不再依次等待四场会议。

高风险事项才进入专业评审：扩大到新的资料类别、自动向客户发送、改变财务事实或让 AI 作出原本没有授权的决定。这样专业岗位把时间放在真正需要判断的地方。

合并后的申请页只有一份。它不能证明风险消失，但能够让申请者、决定人和等待状态同时可见。

FR-25-42 的客户要求项目资料只保存在独立区域，原因是其内部审计规定。公司标准环境当时不支持这一做法。直接拒绝可能失去 160 万元客户，直接绕开又会让权限和恢复责任不清。

经营层批准了一个六十天例外，而不是把客户要求塞进所有项目的共同标准。

例外字段	EXC-25-01 的填写内容
经营价值	维持该客户现有服务并验证区域隔离需求，不承诺新增产品功能
明确风险	独立环境的身份回收、日志检查和故障恢复尚未进入标准平台
保护措施	只开放该客户已批准资料；AI 不对外写入；平台每两周检查访问和备份
负责人	客户负责人承担业务结果；平台负责人承担环境运行；风险负责人复核底线
有效期	60 天，到期不自动延长
退出方式	迁入通过验证的区域能力，或停止该处理并回到人工服务
重新决定条件	第二个价值流出现相同需求，且共享后能减少重复控制

例外不是违规的好听说法。它有范围、期限、保护、主人和回到标准的方法。若到期无人复核，相关 AI 处理自动停止，客户服务回到人工路径。

客户事故发生时，业务负责人可以先暂停危险动作、收紧权限或切回人工。这些是控制影响的紧急动作，不必等待常规审批，但必须在一个工作日内补齐事实和复核。

如果相同例外连续出现三次，我会要求中心团队检查标准是否落后。后来第二个价值流也提出区域隔离，平台才把它列为共同能力候选。一个重要客户的要求不足以替全公司作决定，重复而相似的真实需求才提供复用证据。

两周后的教学观察显示，符合标准的低风险申请从中位数 8 个工作日降到 2 天；未经批准的外部试用没有再次出现；两项高风险申请仍然进入人工评审，其中一项被拒绝。

这些数字只能说明新入口更可用，不能证明未来不会发生违规。公司继续记录绕行、底线触发、决定时间、例外到期和重复例外。

运行手册 0.4 保存了完整的底线与例外目录。它不把每次项目经验升级成全公司命令，也不允许业务用“创新”跳过客户资料和对外动作的基本责任。

治理入口通了以后，各部门的提案一下变得更多。它们看起来都能创造价值，却同时需要相同的工程师、数据负责人和业务骨干。下一节，我把这些无法同时成立的计划放到一张桌面上：六个项目都获批，为什么还是没有一个能快起来。