试点很成功。人工智能模型能回答员工的问题，缩短工单处理时间，或对申请作初步评估；团队也向管理层展示了足以证明这笔投入合理的结果。随后，内部审计、法务部门或客户来问：这个答案从哪里来，数据在哪里，谁对此负责。试点回答不了这些问题，于是模型进不了生产环境，也就是进不了流程的日常运转。建设的钱已经花出去，流程仍然靠人来处理。
为什么试点容易，进入流程却难
试点只回答一个问题：模型能不能做到。生产环境回答的是另一个问题：模型出错时，谁来承担后果。试点阶段，模型使用挑选过的数据，在流程之外运行，查看答案的只有几个人，而且他们知道这只是一次测试。到了生产环境，答案会发给客户、进入记账，或者决定一份申请的结果，后果由公司及其管理层承担。
这一差距的代价可以说清楚。没有来源的答案必须有人手工核对，公司就要付两次钱：一次付给模型，一次付给核对。流出公司的数据，会以律师提问的形式回来：流出了什么，流向了谁，何时流出。无法复现的决策，一旦与客户发生争议，就只是公司的一面之词对客户的一面之词。审计师和律师问的，是试点阶段不必具备的东西，项目往往就停在这里。
模型进入流程之前的三个条件
三个条件都必须在建设之前确定。在已经建成的系统里，每一项都会变成一个单独的项目，有自己的成本和工期。
每个答案都有来源
模型的每个答案都标明出处：合同编号、规章版本、系统中的某条记录。转交这个答案的员工能看到来源，并能核实模型是否读对了。依靠通用知识作答、不给出处的模型，适合用来找思路。在答案会对客户产生影响的流程中，只能使用完全依据公司文档库作答的模型。文档库里存放的是业务部门审核通过的内容。规章变更时，需要更新的是文档库，模型保持不变。
清楚数据在哪里、谁能看到
向模型提供方，也就是模型所属的公司，提出三个问题，就能确定这一条件。模型在哪里运行：在欧盟境内的云上，还是在公司自己的服务器上。谁能接触到提问和答案：公司员工、模型提供方，还是提供方的分包商。提供方记录什么：提问是否被保存，保存多久，是否用于训练其模型。这些答案应以书面形式写入与提供方的合同。有一部分数据，例如客户的个人数据或负有保密义务的数据，根本不进入模型。系统会在发送提问之前将其删除或替换。这一决定要在选择提供方之前作出，因为它决定了哪些提供方能够入选。
决策可以撤回，也拿得出记录
在流程中，模型作出或建议的决策，几个月后可能会被客户、审计师或监管机构问起。每一项决策都需要记录：模型收到了哪些数据，给出了什么答案，由谁批准，何时批准。上线之前要完成风险评估：模型答错时会发生什么，影响到谁，代价多大。凡是对客户有影响的决策（拒绝、收费、变更条件），流程中都保留“人在回路”，即由一名员工在模型的答案发给客户之前予以批准。此外还需要一个停用开关：事先确定好让流程回到无模型状态的方式，以及有权使用它的人。欧盟《人工智能法案》按系统的风险等级规定相应义务，而决策记录、风险评估和人在回路，正是审计师会首先检查的内容。
这对实施方合同和预算意味着什么
三个条件作为验收标准写入与系统实施方的合同，并写明每一项如何检查。检查依据包括：附有来源的答案样本，模型提供方关于运行地点和记录内容的书面确认，已记录决策的样本，以及停用测试的记录。不愿把这些标准写进合同的实施方，等于声明自己交付的只是一个试点。
预算分为两部分，而试点只展示了第一部分。第二部分是上线后的运维。需要有人持续抽样评估模型的答案。规章或法规变化时，文档库需要更新。提供方会发布新的模型版本，切换之前必须先行检验。决策记录不断累积，需要有人审阅。一年的运维价格应当与建设价格并列写在报价中。少了这一项，第一次法规变化之后，模型就会按旧版本作答，而且无人察觉。
团队成员曾在受监管的机构中主导人工智能部署。下面的清单汇集了管理层在验收前无需阅读文档就能提出的问题。
检查清单：验收前的八个问题
- 模型的每个答案是否都标明了来源文件或系统记录，员工能否核实？
- 模型在哪里运行，数据存放在哪里：在欧盟境内的云上，还是在我们自己的服务器上？
- 模型提供方会记录我们提问中的哪些内容，保存多久，是否用来训练其模型？
- 哪些数据完全不进入模型，由谁核实过？
- 每项决策是否都有记录：模型收到了哪些数据，答了什么，由谁批准，何时批准？
- 上线前是否完成了风险评估，由谁签字？
- 谁有权停用模型，流程回到人工模式需要多长时间？
- 上线后一年的模型运维费用是多少，由谁负责？
答案取决于模型要进入的流程：流程中作出哪些决策，依据哪些数据，对客户有什么影响。因此，第一步是在任何人选定模型之前，先对这个流程进行分析。