Hello，大家好。今天我们要讨论的是在银行内部部署人工智能（AI），以及为什么这并非一个单纯的工程问题。在进入正题之前，我想先介绍一下我自己。我叫 Payeyton Gail（佩顿·盖尔）。我曾在多个不同领域工作过。起初，我在埃森哲（Accenture）从事咨询工作。随后我加入彭博社（Bloomberg），担任软件工程师，在交易基础设施团队和数据平台团队工作。之后，我在谷歌（Google）负责安全和部署相关工作。目前，我是一家初创公司的创始全职员工，并正在为 O'Reilly 撰写一本关于部署工程的书籍。
在这个案例中，系统会审查客户文件并为分析师起草例外情况报告。演示展示了预期的工作流程，每个人都能看出它为何有用。然而，安全团队会问：“哪个环境将托管该系统？”数据所有者会问：“谁批准了这种文件使用方式？”风险部门的人会问：“在错误报告到达下一个系统之前，谁将审查这些例外情况？”这些都是合理的问题。每个问题都可能改变我们被允许构建的内容。团队已经在设计阶段投入了大量精力，但负责该设计的几位关键人员却从未见过它的设计方案。
在这种情况下，演示虽然成功了，模型也没有问题，但它最终并未上线部署。我现在要展示的是如何在第一周 uncover（揭示）这些决策点，以便你能够设计出一个拥有可信投产路径的系统。这四个标签代表了你的部署所依赖的决策领域。对于每一个，我需要找到能够解释该决策的人、他们需要的证据以及下一步行动。让我们从数据开始。
关于数据，谁拥有数据来源？谁能授予访问权限？谁能批准在流程中使用这些数据？这些职责可能属于不同的人，但能够查询数据集并不能解决关于应用程序如何使用它的所有问题。对于模型风险，找到能告诉你哪些审查适用于预期用途的人。询问之前的提交是什么样子的。了解谁将在系统上线后拥有该系统，以及该所有者需要什么样的证据来维持其运行。
关于第三方风险，绘制实际的依赖链。包括模型提供商、托管安排以及你在运营服务中的角色。弄清楚哪些关系已经过审查，而哪些拟议的变更需要另一次决策。关于审计，问一问：某人若要重建一个具有后果性的操作行为，需要哪些信息？使用了什么输入？哪个配置产生了输出？审查者看到了什么？谁批准了该操作？这些问题决定了你需要从一开始就捕获的记录。
现在想象一下，在你构建了整个系统、部署边界或可能需要更改的数据路径之后才得到这些答案。更有用的做法是将这些人尽早纳入设计阶段。他们的职责帮助我们识别出我们实际上能够运营的系统的边界。在这里，发现（discovery）就是工程工作的一部分。现在我们要谈谈什么是“发现”，以及我们需要找到谁来确切了解我们需要构建什么内容。
你要认为每个数据集都有一个所有者。我在彭博社数据平台团队所做的工作让我对此有了具体的认识。因此，为大型语言模型（LLM）构建基础设施意味着要理解哪些数据集可以使用，以及谁可以批准这种使用。我们要传达的理念是：每个数据集都有一个所有者。我在彭博社数据平台团队的工作让我对此有了具体的认识，为 LLM 构建基础设施意味着要理解哪些数据集可以使用以及谁可以批准这种使用。
将这一理念带入每一次银行部署，诚然，是任何一次部署。因此，在设计检索机制之前，找到对每个数据源负责的人。确认允许的用途以及处理实际开始发生的环境。如果这些答案发生变化，你的设计也要随之改变。想象一下幻灯片上的钥匙代表一个拥有真正所有者的真实权限。我们应该能够说出那个所有人的名字，以确切知道这个钥匙需要从何处获得。
在开始规划架构时，你提出的许多问题可以通过查看组织架构图来回答。首先阅读第一行：文档进入模型，分析师审查输出。你可能在几分钟内就能勾勒出这个系统的样子。现在阅读下面的一行：文档有一个数据所有者，模型服务需要一个平台所有者，分析师的工作流程需要有人能够确认相关的风险要求。而最后一个名字仍然是一个问号。
那个问号代表一个依赖项。我们设计了一个工作流程，却没有找到能告诉我们其预期用途是否可接受以及需要何种证据的人。因此，我会带着这个图表与赞助商或我信任的人一起过一遍，弄清楚：谁拥有这些文档？他们是否听说过这种用途？谁能帮助我们联系到合适的审查者？然后，我会直接与这些人确认答案。
真正的地图会比这包含更多的关系。一个技术组件可能依赖于多个审批，有些决策贯穿整个系统。关键在于在设计方案仍然容易更改时使这些依赖关系变得可见。一个未命名的所有者变成一个具体的任务，并指定专人负责解决它。这就是“发现”如何将不确定性转化为实施计划的过程。鉴于此，你可能会开始问自己：佩顿（Peyton），我应该提出什么样的问题？
以下是一些我会在“发现”会议中提出的问题：数据存放在哪里，谁可以批准读取它？在类似的项目之前是谁叫停了它以及原因是什么？哪些现有的控制措施可以覆盖此工作流程，谁拥有它们？这个生产环境在哪里运行，该环境的管理员是谁？谁签署相关的风险审查报告，他们之前签署了什么内容？赞助商个人担心的是什么义务，谁能解释它？
请注意我想要留下的结果。要么是人名、决策，要么是关于下一步对话的指引。如果有人说“安全方面没问题”，请问：“实际上会审查设计吗？我们什么时候可以见面？”然后闭环处理。向每个所有者发送一份关于拟议用途的简短描述，并确认他们需要你提供什么内容。到周五为止，部署所依赖决策的相关人员应该知道该项目的存在。这为范围界定提供了一个更坚实的基础起点。
一旦所有这些都完成，并且我们知道谁拥有这些决策权，我就可以对工作范围进行界定。当客户无法编写或提供规格说明书时，我会依靠这三样东西：影子测试、草稿和缩减。例如，在彭博社期间，我参与了一个处理现金流量的系统工作。这项工作必须进行对账。
这是一个具体的切入点。例如，在彭博社时，我负责处理现金流系统的工作必须对账，这给了我一个具体的起点。跟随流程以及对此负责的人员是我采用的方法。当发起人希望引入人工智能用于入职审核时，我会与分析师坐在一起，观察他们打开哪些系统、在何处做出判断以及何时请求许可。询问当文件缺失时会发生什么，并写下实际的步骤序列。这就是你规格说明的开端。
现在想象我们正在构建文档异常助手，这是一个假设的例子，但我仍会将这三行内容摆在发起人面前：第一，审核文档；第二，起草异常报告；第三，分析师提交。接着我会使每一行具体化：分析师可以访问哪些文档？是否已批准对此进行处理的数据权限？模型应生成什么内容，是高亮显示还是起草表格或两者兼有？谁检查草稿？谁负责提交？
对于第一个版本，假设输出为高亮显示的异常和起草的表格。分析师检查源文件、编辑表格并提交，这就是有人可以纠正的边界。我还会提出成功标准：即在无误解增加的情况下减少审核时间。我们仍需同意如何根据当前工作流程来衡量这一点，因为这才是关键所在。在达成一致之前，这只是一个提案。将草案带给发起人及控制负责人审阅。
他们可以划掉某种文档类型，更改审核人员，或者直接拒绝输出结果。每一次修正都提供了一个我们可以据此构建的决策点。一旦工作流程完成，范围界定就变成了一系列审批问题。现在让我们逐步扩展这个假设系统：首先，它总结分析师已拥有的文档内容。我们仍需确认现有访问权限是否涵盖其用途。
接下来，它从第二个系统中读取数据。这里出现了另一条数据路径，需要有人批准该操作。随后，它起草客户将看到的内容回复。谁检查内容？哪些适用的审核标准可供我们使用？最后，它自动发送回复。谁拥有该操作权？如果发错了内容该怎么办？我们如何阻止并恢复错误状态？
这是四种不同的工程范围。适用的审核取决于机构和使用场景，因此我会与拥有这些决策权的人员确认。然后询问哪个增量能在今日创造实用价值？能否在分析师现有的工作流程中起草内容以解决足够多的问题？如果是，就从那里开始。确认现有控制确实适用，并构建具有可信审批路径的最小可用版本（MVP）。
这就引出了自主权问题。我从解决问题所需的最少权限开始，然后询问哪些任务可以作为证据来赋予系统更多权力。在彭博社处理现金流时，我经常思考自动化问题。因此，每一步自动化都需要控制措施并指定负责人。我将这种纪律带入人工智能领域：找出关键操作名称其所有者，决定当系统出错时该怎么办。
例如在假设的异常工作流中，“提交”就是该关键操作。分析师审查草稿时需要源证据和可见的不确定性才能做出真实判断。如果人员实际上无法检查工作，仅有一个“审核”按钮是毫无帮助的。因此在思考自主权时，我希望你自下而上阅读这个阶梯：建议意味着分析师收到推荐并自行决定如何处理。
起草是指系统准备内容，由分析师检查并提交，这是一个高亮显示的步骤。“经批准行动”意味着人员在操作发生前授权每一步。自主运行是指系统在已批准的范围内运作。每个步骤都会改变错误的后果，同时也改变了哪些控制必须生效以及需要说服哪位审核人员。
我会从创造价值的最低步骤开始，然后从中收集证据：审查是否覆盖了草稿？哪些故障反复出现？当出现问题时人们能否恢复？利用这些观察结果做出下一次权限决策。模型不会自行变得更强大，你需要回答该特定工作流应赋予它多少权力。
现在让我们用同样的假设异常助手来具体说明：初始请求是一个代理，它读取客户文档，决定哪些超出政策范围并自动提交异常。在这种设计中，模型的判断可能在没有分析师逐一检查每个案例的情况下成为操作行动。现在保留模型但改变动作边界：它高亮显示可能的异常，指向相关源文件并准备草稿表格。
分析师检查证据、修正表格并选择是否提交。遵循幻灯片上的序列：模型、人类、提交。我会将这种设计带给我们在发现阶段找到的人员确认：这能否利用分析师现有的工作流程？已批准的数据访问是否涵盖处理过程？哪些控制适用？审核人员需要什么样的证据？
人工审查并不能保证批准，也不能单独决定监管类别。我们仍需确认预期用途和所需的审核流程。有用的问题是这种起草版本是否解决了足够多的问题以便先行发布？如果确实如此，我们可以在该边界内运行时收集关于错误、覆盖和恢复的证据。下一次权限决策可以基于实际使用中的情况做出，这使得评估成为运营计划的一部分。
这就引出了我们的第四个承诺：一个风险团队可用于证据的评估机制，这实际上意味着他们负责管理的那些事项。在谷歌时我需要回答的问题是：当系统崩溃时会发生什么？谁注意到问题？什么会停止运行？谁承担责任？恢复上线需要多长时间？对于人工智能部署，我也想要同样具体的账户：预期用途、威胁模型、故障模式以及响应计划。
向我展示当模型出错时控制措施是如何运作的。指明接收警报并能够停止工作流的人员姓名，这就为我们的例子提供了一种实用的评估方法。回到我们可爱的假设异常助手示例：如果它编造了一个异常，分析师检查源段落并拒绝草稿；如果提取产生不可读文本，则停止并要求提供清晰文件；如果它遗漏了异常……
针对性的离线案例有助于暴露这些弱点。它们无法检测所有实时遗漏的情况，因此需将受影响的工作保留在人工审查之下。对于每一次失败，都要明确检测路径、回退机制及其负责人，并将这些决策放入证据包中。这五个文件使审查工作完整：预期用途、记录用户、边界和禁止行为；数据血缘，记录每个示例的来源和使用情况。
批准方面需记录故障模式、按细分领域记录的检测与回退结果，以及覆盖率、错误控制措施；审查方面需记录阈值、停止规则和负责人。有了所有这些内容，我们在每次评估运行时生成证据包，同时保留输入提示、模型版本配置、输出、审查者操作等信息，以便我们重建历史决策。稍后再次调用模型可能会产生不同的答案，所以我们保留实际发生的情况。
审查者可以期望看到这些支持性记录。现在我们可以看看第四份文件中究竟使用了什么来组织结果。对于假设的工作流，我会将清洁文档、扫描件、罕见异常和新文档类型分开。测量每组中的错误和控制行为，然后以最弱的结果为主导。平均值可能会掩盖某一细分领域的严重差距。
如果某组证据较少，请说明这一点，并在拥有足够证据之前限制该用途。这告诉审查者结果支持什么内容，同时也让我们回到第一周的决策中。现在，到周五时我要五个问题的答案：数据所有者是否参与并了解此项目？生产环境及其管理员是否已明确指定？发起人能否在不提及“AI”的情况下描述工作流？最小可用范围是否能适应现有控制措施，并得到负责人的确认？
我们是否知道风险签署人以及上次签字的人发生了什么变化？将这些答案作为规划启发式方法。四个或五个“是”表明有一条可信的交付路径；三个意味着未解决的决策需要负责人和日期；零到两个“是”则意味着在承诺交付之前必须解决这些决策，包括可能缩小范围甚至重新定义范围。
这个分数并不能预测批准结果，但它确实告诉我们在接下来的一周该在哪里投入精力。以下是我将带入这些后续讨论的内容：总结一下，我希望人们离开时带走这样的认知——发现过程本身就是工程工作。起草规范，然后缩小范围；只给予系统必要的权限；在第一个冲刺周期构建证据包。演示成功了，模型也没问题，但它仍然没有上线。
那我们该怎么办？我们去找到相关人员。感谢您与我一起完成这次演示。我是佩顿·盖尔，一位部署工程师，正在为 O'Reilly 撰写关于 FTE（功能测试环境）的书籍。是的，我很乐意谈论 FTE 及其相关内容。如果您感兴趣，可以在 LinkedIn 或我的网站 painting.com 上找到我，那里有我所有的信息。再次感谢您今天的观看，期待与您交流。