你的 AI 功能路线图从未计算过的法律审查时间表

你画了一个包含六个季度的 AI 路线图。模型切换、新数据源、多语言发布，以及现在提供建议的提示词，在甘特图上各占一行，并根据工程量的大小确定了尺寸。接着，第一次发布推迟了四周，而复盘报告在三个不同的章节里重复了三次同样的话：“正在等待法务。”路线图原本假设工程能力是关键限制。而实际的瓶颈约束是一堆法务审查队列，每个审查都有自己三到六周的 SLA，且彼此互不知晓，最终全都压在仅有的两名产品法务身上。

错误并不在于任何一项单独的审查。每一项都是有理有据的。错误在于将四个并行功能视为四个并行的时间线，而它们的法务依赖却通过同一个上游资源进行串行处理。到第二次延期时，组织了解了问题的轮廓。到第四次时，它学会了针对此进行规划。那些能够以可预测节奏发布 AI 功能的团队，已经不再将法务吞吐量视为外部的意外，而是开始将其视为与人力和基础设施容量同等地位的规划输入。

为什么 AI 路线图会成倍增加审查面

常规功能只触及一两个值得审查的属性：这里有一个 UX 更改，那里有一个数据字段。而 AI 功能触及的更多，且每一次触碰都可能重新开启审查。模型切换会改变备案的数据处理者，并可能改变数据保护法下的法律依据。新的训练语料库会引来关于来源、许可，以及上游许可在衍生用途中是否依然有效的问题。多语言发布跨越了司法管辖区，并引入了欧盟《人工智能法案》的透明度义务、英国新兴的指南，以及美国半打州法律。提示词的改变将“总结”功能转变为“建议”功能，可能会根据《人工智能法案》的风险等级对整个系统进行重新分类，并伴随相应的文档要求。

2025 年的监管浪潮让这一切变得具体。欧盟《人工智能法案》于 2024 年 8 月生效，并开始在 2025 年和 2026 年逐步履行义务：2025 年 2 月禁止受限系统，2025 年 8 月实施通用模型规则，2026 年 8 月广泛适用，2027 年 8 月履行高风险义务。每个阶段都增加了一个法务必须对照执行中的路线图应用的检查列表，且每个阶段都扩大了“可审查变更”的定义。在 2023 年可能只是发布说明中一行字的模型升级，现在很可能是一个带有专属文档包的监管事件。

那个以工程周为单位计算每个功能成本的路线图，并没有考虑到这些。法务队列是路线图遗忘的队列。

你看不到的队列正是决定发布日期的队列

法务队列建模不足的第一个症状在每个组织中都是相同的：日期在被打破之前一直能对上，然后就会一起延后。三个不同团队的三个功能大约在同一周发现，他们的审查仍在挂起。团队互相指责对方的审查“阻塞了我们的审查”。法务团队指责从未配备足够人员的负载。路线图所有者指责日历。

共同的特征是，没有人像管理队列一样管理这个队列。审查通过 Wiki 表单、Slack 私聊和季度入职会议进入。它们没有公布 SLA，没有在途计数，没有分流准则。产品法务同时阅读其中三个，而工程团队没有可见的“你在队列中排第 4 位，预计三周后开始”的信号。这是法务中最像未受监控的微服务的部分：一个服务于饱和线程池的单一端点，调用者唯一的可见性就是响应最终是否返回。

诊断结果很乏味，修复方法更乏味。像对待任何面向生产的服务一样对待审查准入。公布 SLA。公布当前的队列深度。发布分类列表，以便工程师可以提前看到他们的更改是落在现有范畴内，还是触发新的审查。跟踪准入率、清理率和入队时间百分位数。这些都不是新鲜事。唯一新鲜的地方在于，组织从未想过将其应用于法务职能。

常设范围（Standing Envelope）是最高杠杆的操作

常设范围是指预先批准的范围，在此范围内的一类变更无需经过新的法务审查即可发布。典型的例子是已经通过审核的营销模板，新的资产显然“在红线之内”。对于 AI 功能，这种范围更难起草，但价值却大得多，因为边际审查成本主导了进度。

这种范围是法务和工程之间的一份契约，它规定：对于这种形式的变更——相同的数据源、相同的风险等级、相同的外部界面、白名单内的模型切换、此类别的提示词更改——团队可以根据发布的自我确认（Self-attestation）进行发布，法务将进行抽样审计而不是预先审查。这种交易是明确的。法务放弃对范围内集合的准入审查，以换取对范围外集合进行更敏锐、更快速的审查。工程团队放弃了默默扩大范围的自由，以换取留在盒子内的变更能够拥有可预测的发布路径。

范围的形状比大小更重要。一个覆盖 60% 计划变更的小范围，比一个需要 90 分钟阅读练习才能判断变更是否合格的大范围更有用。范围应该在一页纸内可读。它应该有一个实际案例。它应该有一个明确的范围外触发列表——增加新数据源、更改法律依据、扩展到新的司法管辖区、将输出从信息性转变为建议性——以及一个明确的范围内确认步骤，该步骤会生成记录在案的自我确认。这种确认是使范围可审计的产物。

实施这种范围的团队发现，70-80% 的审查量都落在其中。剩下的 20-30% 是真正的创新工作，这正是值得仔细预先审查的工作。法务团队现在正在审查正确的事情，而不是因为没有分流方法而对每一项变更都进行预先审查。

嵌入式法律顾问是周期干预手段，而非成本项

在功能团队中嵌入产品法律顾问是每个领导团队在理智上理解但在操作上抵制的一种做法，因为它看起来像是增加了人力，却不产生可部署的产出物。这种抵制在计算上是错误的。嵌入式法律顾问不产出代码；它在团队交付的每个功能上压缩了周期时间。一次为期四周的审查之所以变成两天的对话，是因为法律顾问参与了设计评审，这就是全部的 ROI 计算。

这种做法奏效的结构性原因是：最昂贵的法律反馈是迟到的反馈。在节点评审（gate review）时才了解功能的法律顾问只能说“停止并重做”。而参与了方案评审（spec review）的法律顾问可以说“可以，如果你这样做”。“可以，如果”是这种产出物，它能将强硬的拒绝转变为可行的设计。这也是当法律顾问在 PR 完成时才第一次看到功能时，往往无法产生的东西。

领导层的举措应该是根据 AI 路线图的节奏来配备法律人员，而不是根据历史法律工作量。历史工作量是一个滞后指标，它衡量的是一个为更慢的世界而设计的职能部门。未来的工作量取决于路线图实际打算每季度交付多少次 AI 变更，乘以超出既定合规边界（standing envelope）的比例，再乘以平均评审深度。这个数字就是配员目标。如果职能部门相对于该目标规模不足，路线图就会滑坡，在每次复盘中原因都会写着“等待法律评审”，这是症状而非诊断。

将法律管线视为规划输入，而非上线惊喜

能在未来八个季度幸存下来的路线图，是那些将法律评审估价为与工程投入具有同等精度的路线图。这意味着路线图文档要发生三个具体变化。

• 每个 AI 功能行都带有一个法律成本估算，与工程周数估算并列。估算单位是排队周数（queue-weeks），而不是律师小时数，因为排队周数才是日历上感受到的。在既定范围内的模型切换可能消耗零个排队周。一个新的数据源可能需要六个。估算只是猜测；猜测这种约束力才是迫使对话发生的动力。
• 共享同一个超出范围法律依赖的功能会被标记为共享资源冲突，就像两个功能需要同一个 SRE 值班人员时会被标记一样。忽视这一点的甘特图是在进度上撒谎。
• 既定合规边界每季度都要像架构路线图一样严肃地进行审查。边界随着监管的漂移而漂移。在第一季度制定了边界但在第三季度遗忘了它的团队，到第四季度会发现他们一直在自证明模式下交付的内容，有一半已经不再合规线内了。

还有第二层领导力举措，即把法律合伙人视为路线图的共同负责人，而不是下游消费者。共同负责人参加路线图评审。共同负责人会回绝那些形态上需要超出范围评审、但团队忘记预算的功能。共同负责人的评分部分基于已交付的功能，而不只是完成的评审。评分体系的变化将该职能与路线图对齐；如果没有它，该职能就会被激励去进行彻底且缓慢的评审，这是产生全局观察到的延期的局部最优策略。

前瞻视角

2026 年的监管前景不会变得更便宜。欧盟 AI 法案（EU AI Act）于 2026 年 8 月开始广泛适用的日期，对大多数公司来说是在年中到来。高风险义务将在 2027 年 8 月落地。美国州级法律继续以大约每季度一个新重要监管体系的速度出台。每一个新体系都是评审清单中的一个新列，也是既定边界必须重新验证的一个新维度。

那些建立了排队机制、起草了边界、嵌入了法律顾问并将法律成本计入路线图的团队，将把每个新监管体系吸收为一次边界修订和一次重新配员决策。而那些没有这样做的人，将把每个新监管体系吸收为一次路线图重新规划和一整个季度的上线延期。

领导力的教训是十年前每个基础架构团队在数据库方面学到的：一个吞吐量决定你交付日程的职能，不是供应商或外部服务；它是你生产栈（production stack）的一部分，它需要任何生产栈组件都具备的检测工具、SLO、容量规划和所有权。AI 功能的法律评审现在就是这个职能。不计成本的路线图是在一份从第一个冲刺（sprint）开始前就已错误的计划下进行交付。