金融与保险：可用之外，还要可追责

2026 年 4 月 22 日，花旗公布了 Citi Sky。一位客户将来可以通过语音和虚拟形象，与这位财富管理团队的 AI 成员交流。公告明确写出，花旗与 Google DeepMind 应用团队、Google Cloud 的前线部署 AI 工程师共同开发相关能力，并计划从当年夏季起，向美国 Citigold 客户分阶段开放。¹

到了 9 月 22 日，花旗另一篇官方文章的图片说明，仍将 Citi Sky 描述为正在由部分美国员工和客户测试。² 两个日期之间不能直接画上一根“全面上线”的箭头，也不能据此断言项目延期：分阶段推出本来就可能包含受限测试，公开材料没有给出完整发布记录。可以确定的是，银行把产品展示给公众，与银行愿意让哪些客户实际使用，是两个不同决定。

这一区别把金融 FDE 的问题摆到了台面上。会话可以在几秒钟内完成，背后涉及的资金和合同，却不会随着对话窗口关闭而消失。一个系统可以正确理解客户说的话，同时没有得到执行这句话的权限。它也可能准确提取一份材料，却把材料用于错误的保险申请。客户最终要面对的是自己的账户、保单和申诉，不能只得到一句模型已经通过测试的回答。

Citi Sky 提供了明确有 FDE 参与的银行案例。保险部分则选用保险企业美国国际集团（AIG）已披露的业务与技术伙伴共建过程，作为相似交付模式比较；材料没有证明其中每名工程师都使用 FDE 职称。把两者放在一起，是为了看清同一种现场难题的两面：怎样帮助人更快理解信息，又怎样控制信息进入正式决定的那一步。

从一次提醒，到一项授权

花旗与 Google Cloud 的合作早于 Citi Sky。2024 年 10 月 28 日，双方宣布多年战略协议，计划迁移部分应用和工作负载，并把生成式 AI 用于开发工具、文档处理与客户服务。³ 这是一项基础设施和能力建设安排，不能拿来充作 Citi Sky 的开工日期。到面向客户的会话产品出现时，问题已经从“员工能否调用模型”，向“客户如何理解银行的回答”移动。

Citi Sky 公告列出的首批功能中，有银行存款凭证到期提醒，也有财富管理首席投资办公室提供的市场信息。存款凭证可以先简单理解为有约定期限的存款产品。仅仅围绕“这笔钱快到期了”，工程团队就会遇到三类性质不同的工作：找到账户事实，解释可选事项，以及接受一项会改变账户的指令。公告披露了功能方向，没有披露交易授权的完整设计。下面沿这条提醒继续推演，是教学分析，不是花旗内部流程实录。

第一步看起来最容易：找出哪笔存款、何时到期、信息更新到了什么时候。然而，问“我的存款什么时候到期”，与问“这类存款通常有多长期限”，需要完全不同的数据。前者必须确认客户身份和可访问账户，后者可以来自产品资料。若把两种回答都交给同一个泛化搜索入口，系统即使没有泄露任何秘密，也可能把产品的一般条件说成客户已经签订的条件。

所以，工程上需要保留的不是一段看起来完整的答案，而是答案与对象的关系。账户事实应当能对应到确定记录，产品说明应当有适用版本；两者拼在一句话里，来源仍须分得开。过期的信息不能因为语言流畅，就获得新的有效期。这个要求并不神秘：人类顾问也需要辨别手里的资料，AI 只是把原来分散在多个页面里的辨别，压缩进一次交互。

第二步是解释。假设客户想了解到期后可以做什么，系统也许能够介绍选项。但一般选项、适用该账户的选项、适合该客户的建议，并非同一层意思。工程师不能仅凭模型很擅长概括，就决定跳过这些层次。哪些内容允许自动说明，哪些须由顾问进一步判断，应由业务和控制团队确定，再落实到系统允许获取的资料和可以发起的动作中。

第三步才是授权。客户说自己倾向某个选项，并不等于一笔业务已经具备执行条件。在这个教学流程里，负责账户业务的人员应确定：需要确认什么内容，谁有权同意，确认后交给哪套系统执行。工程团队的职责，是确保一个建议不会在界面上被悄悄变成已执行的结果。例如，画面上可以明确区分“信息已整理”“等待确认”“业务系统已受理”，而不是把所有状态压缩成一个完成勾号。

语音让这个区别更容易被忽略。客户可能在一句话结束之前修正意图，也可能用“好”表示听懂了介绍。把每一次肯定都当作交易确认，会使自然对话的便利反过来损害明确授权。需要额外确认时，系统可以暂时放慢，而不是让模型猜测。这种节奏应随动作后果变化：多问一次公开资料，没有必要走完整交易流程；变更账户安排则不能沿用同样的默认许可。

FDE 若参与这类产品，潜在价值在于把模型、界面和客户已有控制系统之间的空隙补齐。具体到现场工作，是与顾问、产品负责人和账户系统工程师逐段走过一条请求，找出各自以为已经有人负责、实际上没有交接清楚的位置。这个价值不能由职衔担保。花旗公布的协作成员和技术方向，证明有这样的合作；公开材料尚不能让我们计算它减少了多少错误、节省了多少人工，或怎样分配双方的长期维护费用。

保险先处理材料，再承担风险

银行对话从客户一句话进入，保险核保通常从申请材料进入。核保，就是判断是否承接一项风险，以及按什么条件承接。若资料准备占据大量注意力，专业判断可用的时间就会被挤压；但把准备做快，也不等于应该把承保决定一并自动化。

2025 年 3 月 31 日，AIG 在投资者日披露，核保助手已在美国部分金融险业务投入生产。演示先列出旧流程：人员提取、检查申请资料，开展内外部研究，再补充信息。新流程把提取、汇总与重新排序放在前面，核保人随后分析 AI 输出，再进入报价等步骤。变化发生在专业决定之前的准备工作，并未取消作决定的人。⁴

公开分工中，AIG 提供业务知识与数据，Anthropic 提供模型，Palantir 承担数据连接和流程能力，亚马逊云服务等参与资料处理。材料把业务共建、人工参与作为开发原则，并列出核保人提出的功能增强需求。⁴ 这能看见客户反馈进入交付，却还不足以复原某位工程师改了哪一段代码。读者可以沿明确的分工追问：资料字段换了含义，谁调整读取，谁调整传递，谁确认它仍能进入核保？

这个顺序比“AI 做保险”更有解释力。资料摄取解决怎样把不同文件中的信息取出来；排序决定哪些申请先得到注意；补充信息则将内部知识与外部资料加入判断准备。三步的输出都可能影响后续决定，但影响的方式不同。一个姓名提取错误，会把材料归到错误对象；一个排序规则偏差，会让某类申请长期排在后面；一段不合适的补充材料，则可能改变核保人对风险的理解。

可以用一份明确虚构的教学申请来跟随这个流程：某企业向保险公司提交当年财务表，随后补交修订版。旧版和新版的文件名相近，其中同一项金额发生变化。若系统只追求填满字段，可能把旧数字保留在摘要里；若系统只追求最新上传时间，也可能把一份无关附件当成修订。这里真正需要业务决定的是：什么材料具有替代效力，发生冲突时先找谁确认。

在合理的设计中，负责接收申请的人确认文件属于哪项业务；系统保存版本关系；抽取结果回到具体页码或段落；核保人能够看见差异，并决定是否要求补件。工程师可以帮助这些动作连续发生，却不该替核保人决定某个矛盾是否可以接受。如果把冲突直接消解成一段流畅总结，最节省阅读时间的界面，反而可能让最重要的判断条件消失。

这还揭示了“有人工审核”的两种版本。第一种版本是人看到一个结论，只能选择接受或退回。第二种版本是人能检查结论依据，看到未解决的冲突，修改关键字段，并知道修改会影响后续哪一步。两者都可以统计为人工参与，所需的注意力和纠错能力却很不一样。前者可能只增加一次点击，后者才给专业判断留出实际空间。

人工当然也可能判断错误。保留审核人，不是要求一个人检查每个字符，更不是用其姓名吸收全部系统风险。可以让稳定、可核对的字段自动流转，把注意力集中到新情况、冲突信息和超出授权范围的事项。专业人员的注意力花在哪里，应该由错误后果和材料性质决定，而不是由哪个位置最方便放一个确认按钮决定。

AIG 对外宣称，助手可以在一天之内整理好供核保人员审阅的申请。这个口径是资料准备，不是每份保单都在一天之内完成承保。公开展示也没有给出足以独立复算的样本和对照。把阶段读准，才能提出更好的后续问题：准备时间缩短以后，核保人是否减少重查，补件是否更少，还是只是更早收到了需要重新整理的材料？

错误要有能走回去的路

一份错误摘要尚未被使用，受影响的业务范围可能较小，但仍要查清错误从哪里产生，修正相关环节并保留更正依据。若决定已经依赖它，还要向后追到受影响的工作和人员。未用与已用，改变的是追溯范围，不是只修最后一段文字就算完成。

2024 年 7 月 11 日，纽约州金融服务部发布关于保险核保和定价使用 AI 及外部消费者数据的指导信。它保留了保险公司的责任，要求对第三方错误资料设置反馈、调查与纠正程序；对于不利核保或定价行动，不能以供应商算法专有为由，拒绝给出具体解释。⁵ 这是有明确辖区和业务范围的监管要求，不是全球保险业务的一张统一许可证，但它清楚说明了客户为何不能把责任随着软件采购一并交出去。

沿用前面的虚构教学申请 A-17，把记录填出来。上一期收入为 1,000 万元；申请方先交来的当期财务表 v1 写 1,200 万元，后经其确认，v2 的 900 万元替代同一期间、同一字段。这里的金额、时间、人员分工和处置全部用于教学，不是 AIG 的客户资料或核保规则。

20% 来自（1,200－1,000）÷1,000；更正后是（900－1,000）÷1,000＝－10%。工程人员能改取件规则和摘要，却不能把这次变化自动转换成拒保或更高价格。是否需要补件、怎样评估风险，仍由业务人员依据完整材料决定。

这份记录也让两条分支分开：如果 S1 从未被使用，查明使用范围后便没有 J1 要重审，但取件错误和验证仍要完成；如果它已经进入对外决定，便不能照抄本例“无须撤回”，必须按适用程序继续处理受影响事项。关闭记录的人要能指出依据，不能只看待办变绿。

可复制的已填更正记录与空表保留了文件、字段、摘要、决定和负责人之间的关系。它不要求员工保存无限记录，而是让下一位接手者找到旧值走过的路。若把 S1 直接覆盖，或者只有一长串聊天记录，这条路仍可能断掉。

更隐蔽的问题发生在排序上。如果 AI 把某类申请放到队列后面，系统尚未拒保，客户却可能等不到及时处理。因此，审查不能只盯着最终“同意”或“拒绝”的按钮，也要观察哪些工作长期没有进入人的视线。这是由工作流分析得到的风险，并非 AIG 已被证实发生的事故。它提醒团队，效率要同时从服务获得者和处理者两端看：平均速度变快，可以与一部分申请持续受阻同时存在。

这时可以做一个具体的对照。保留原处理流程的一批适当样本，把自动排序与原来的处理顺序比较，检查被推迟的申请有什么共同特征，再由业务、风险与工程人员分别解释变化。这样的核验不必等待经营年度结束，也不必先证明整套 AI 优于所有人工。它只要回答当前被改变的那一步，是否出现了不愿接受的后果。

引用找对了，计算也要走对

前面的申请已经有正确文件，仍要正确计算收入变化。金融研究把这一要求放大：选哪几个季度、怎样处理重述的报表、一个术语在当前问题里究竟指什么，都可能改变结果。

2026年4月，Anthropic介绍金融研究平台Kepler时，描述了一种分工：模型解释问题、处理歧义并形成计划；专门的计算环境执行公式和期间处理；输出中的数字可以追到原始文件的具体条目。团队称，它会分别检查计划和计算结果。⁶ 这是厂商披露的产品设计，不是本书独立完成的准确率审计，也没有证明其所有项目都由FDE交付。

值得带走的是这项分工，而不是“可追溯就不会错”的承诺。沿用申请A-17，上期收入仍是1,000万元，改变的是当期收入：从1,200万元更正为900万元。点开脚注能看到900，并不证明算式也已换值；如果计算仍取1,200，系统就会继续误报增长20%。即使计算正确，读者问的是现金流、系统却回答收入，也没有答对问题。取证、计算与业务解释需要分别经受检查。

因此，给客户展示一串脚注并不足够。一个值得验收的结果，应让接手者看清这次采用了什么定义、输入了哪些数、怎样计算，以及什么疑问还留给有资格的人判断。这并不要求模型承担每一步；明确把某些步骤交给规则和计算程序，反而能让专业人员把精力放在真正存在歧义的地方。

多家供应商，不能变成多处责任空白

从银行会话到保险资料处理，模型只是系统的一部分。账户记录、文件接口、检索工具、业务规则和使用界面可能分别由不同团队维护。一个供应商可以证明自己的组件按约定运行，却无法独自证明组合之后的业务行为始终正确。

英格兰银行与英国金融行为监管局于 2024 年 11 月公布的调查，收到 118 家机构回复。报告显示，受访机构约三分之一的现有 AI 用例由第三方承担大部分开发或部署；部分机构使用原有评估框架，另有机构为 AI 增加特定条件。⁷ 这不是全球 FDE 数量统计，却足以提醒我们：对外采购和内部控制本来就需要同时成立，新的岗位名称不会取消这种关系。

设想资料提取所用模型升级了，读取表格的表现整体改善，却改变了空白栏目的处理方式。业务系统以前把空白理解为尚待补件，现在模型可能主动填入一个推断值。数据格式依旧合法，接口也没有报错，后续排序甚至更顺畅。只有回到业务含义，才能发现未提供资料被改写成了已经提供的资料。

这类变化应先由工程团队识别影响范围，再让业务负责人决定能否接受新行为；涉及已有评估结论的部分，还应交给相应控制团队复核。供应商可以提供版本说明和测试支持，机构自身则需要知道哪些正在运行的工作依赖这个版本。若所有人都只承诺各自组件没有出错，组合出来的错误就找不到处理者。

FDE 靠近客户，有机会较早发现这种语义变化；靠近平台团队，又有机会把现场发现转成可复用的产品修正。但这种靠近必须对应实际可做的事。不能修改的平台，需要清楚的反馈与升级路径；不能直接接触的数据，需要在合适权限下定位问题。用一个能够随时找来的工程师代替这些安排，会把机构的持续能力寄托在某个人是否还在线。

AIG 在回顾 2025 年的年报中，已描述核保能力扩展，并称部分理赔环节也在应用相关技术；同时，它把控制智能体何时启动、能访问什么、怎样排列任务及何处需要人工监督的编排能力，写为仍在发展的工作，并列入 2026 年重点。⁸ 这里的编排，可以理解为给不同自动化动作规定先后、条件和交接方式。单项能力投入使用，和整套行为已经得到稳定组织，显然不是同一天完成的事。

因此，金融交付的维护预算不能只覆盖模型调用。还要有人处理资料规则变化、产品版本变化、用户提出的纠正，以及外部组件升级。现有原件没有披露 Citi Sky 和这组 AIG 能力的完整成本，无法据此算出统一回报率；但评估具体采购时，这些工作必须进入比较。否则，一套表面便宜的系统可能把持续解释和重查留给客户员工。

快了以后，究竟获得什么

两类流程提供了不同的衡量起点。会话助手可以检查客户是否找到了正确事项、是否需要反复转接，以及在进入正式业务前是否明确理解当前状态。核保助手可以检查资料准备和复核耗时、纠错后是否重新处理，以及专业人员是否获得更多有效判断时间。它们都比“回答生成得多快”更接近使用价值。

经营结果则要继续向后看。客户满意度可能受到服务安排影响，保费增长可能受到市场价格和业务组合影响，损失表现还需要经历相应风险周期。不能因为 AI 在同一年被部署，就把同一年的所有改善计入工程团队贡献。反过来，也不必等到利润全部可归因，才承认一项经过验证的流程改善。关键是按证据所在的层次作判断，不把局部收益说大，也不把它说没。

如果任务只是从稳定字段生成到期提醒，成熟业务系统加简单规则可能更便宜、更容易维护。若内部团队已能完成模型接入和控制设计，外部工程师也可能只需提供短期技术支持。对于信息来源固定、动作有限的任务，扩大驻场队伍未必带来价值。

FDE 更可能有用的场合，是机构正在探索一种尚未稳定的工作方式，而且平台限制、业务语义和用户反馈必须一起调整。此时，需求不能只在开工时交一次，问题也不能每次都沿长长的供应商工单链往返。双方需要能把一个真实请求走通的人，并允许他们把反复出现的问题送回产品。这种安排是否值得，要比较额外协作成本与缩短反馈距离的收益。

回到 Citi Sky 的两个日期，受限测试给我们的信息有限，却并不空洞。它说明读者应该追踪产品究竟走到了哪一层承诺。下一份有价值的材料，应进一步说明哪些客户得到服务、能够完成哪些动作、异常由谁处理，以及持续使用带来什么变化，而不只是再展示一次更自然的对话。

金融现场工程最终要交付的，是一个让机构敢于承担、也能够解释的工作过程。客户的话怎样变成请求，资料怎样变成判断依据，判断怎样进入有效决定；这些连接处清楚了，系统才能既有用，又能在被追问时给出具体答案。