网络研讨会回顾：欧洲最大保险公司之一如何将 AI 智能体投入生产

保险客户很少会在一切顺利时来电。他们通常在发生事故后、需要提出理赔时，或正处于真正的危机中才会打来。这段对话会影响之后的一切，也往往是客户与保险公司之间唯一真正的互动。

Admiral 每年在英国、意大利、法国和西班牙处理数百万次这类对话。如今，他们正借助 AI 智能体协助处理这些对话，同时保持合规。

在这场网络研讨会中，Admiral 团队介绍了具体做法：选择首个用例、从项目第 0 天就让法务与合规团队参与，以及如何从可用原型发展到数小时内即可上线生产变更。

核心要点

• 从范围小但真实的用例开始。 Admiral 在英国贷款业务中首个投入生产的用例是结清报价。它的范围足够明确，能在实际时间表内上线，同时又涉及电话系统和后端集成，足以验证架构，而无需一次解决所有问题。
• 扩展前提高标准，而不是降低标准。 Admiral 从第 1 天起便面向生产环境构建，重建治理节奏以跟上技术发展，并通过范围明确的试点项目，让法务与合规团队从第 0 天参与。
• 监管只是底线，不是全部设计。 Admiral 在监管要求之上增加内部规则，对必须可证明的事项采用确定性逻辑，并将脆弱或情绪困扰的客户转接给人工客服。
• 真正的工作从生产环境开始。 每项智能体变更都会经过完整模拟测试套件，并从 1% 流量逐步扩展到 100%；这一周期已从数周缩短至数小时。

从范围小开始，但不要过于狭窄

Admiral 首个投入生产的用例是其英国贷款业务中的结清报价。这是一个有意选择的可控起点，而不是清单中最棘手的问题。Kampa 将这种方法概括为：先选定一个国家和一条业务线进行试验，再逐步扩展。

Neely 表示，这正是能够上线生产的部署与停滞不前的部署之间的区别：用例既要足够聚焦，能在实际时间表内解决；也要足够复杂，能够真正检验周边系统。结清报价之所以适合，是因为对话路径有限，但仍涉及电话系统和后端集成，足以验证架构，无需试图一次解决所有问题。

这一选择中有几个关键因素：

• 范围明确，复杂度真实。 用例需要有足够的变化来测试电话系统和后端集成，而不只是预设的顺利流程。
• 快速投入生产。 项目在开发阶段停留越久，真实对话产生真正有助于改进智能体的反馈就越晚。Neely 将此称为“最后 20%”，即只有真实客户开始与系统对话后才会显现的部分。
• 兼顾规模与影响。 Admiral 从简单、高频的互动开始，在这些场景中，缩短等待时间和加快问题解决能显著改善客户体验。

扩展前提高标准，而不是降低标准

Admiral 管理层明确表示，AI 智能体应提高合规与测试标准，而不是降低标准。Kampa 直言，验证标准必须比过去更严格，因为智能体偏离脚本或违反规则的风险，与人工客服作出判断的风险本质不同。

这一标准体现在团队早期作出的三项承诺中：

• 面向生产环境构建，而非只做概念验证。 Kampa 要求团队从第 1 天起就以正式上线为目标进行设计，而不是开展一个永远无法扩展的小型实验。
• 与技术发展速度同步的治理机制。 Kampa 指出，如果一项审批要花 6 个月，获批的技术在上线时可能已经过时。Admiral 重建了审核节奏，以匹配底层模型和工具不断变化的速度。
• 从第 0 天起让法务与合规团队参与。 当被问及法务与合规团队何时加入项目时，Kampa 和 Clark 都立即回答：第 0 天。团队采用范围明确的试点项目（规定通话数量），而非提出一个无限期的审批请求。

让监管设定底线，而不是决定全部设计

Clark 明确指出，英国、意大利、法国和西班牙的监管要求各不相同，例如是否需要告知客户其正在与 AI 对话，以及在某些司法辖区是否必须提供转人工服务。Admiral 构建智能体来应对这些差异，同时不会让任何一位来电者通过“升级”转接，避开本可解决的对话。

某些对话完全不由智能体处理：Admiral 会将脆弱或情绪困扰的客户转接给人工客服，并训练 AI 识别触发这种转接的信号。

Kampa 将更广泛的方法描述为分层设计：“监管只是底线。”在此之上，还有 Admiral 自己的内部规则与文化标准，有时甚至比监管要求更严格。

这种分层方法也决定了 Admiral 在何处使用确定性逻辑或非确定性逻辑。Clark 解释说，非确定性推理适合理解来电者意图或识别情绪困扰；而任何业务上必须可证明的事项、必须作出的监管声明，或客户必须遵循的路径，都必须通过确定性逻辑执行，绝不允许智能体即兴发挥。

Neely 介绍了 ElevenLabs 的 workflow 结构如何在实践中支持这一点：智能体由一组专业子智能体组成，并通过认证等确定性关卡，根据是否满足条件来开放或限制功能，而不是让模型自行推断它可以做什么。

与流程负责人共同构建

Admiral 和 ElevenLabs 没有采用业务需求与工程开发之间的传统交接模式，而是举办了现场工作坊，让熟悉用例的人员、工程团队和电话系统团队齐聚一堂。Neely 表示，第一次工作坊就在 4 到 5 小时内完成了一个可运行的智能体 v0，并接入后端和电话系统，Kampa 和 Clark 随后可以在内部演示它，以争取继续开发的批准。

Clark 表示，这种紧密协作的价值不止体现在第一个原型上：业务负责人如今已足够接近这项技术，能够自行进行一些修改。因为工作坊将平台视为迁移既有业务流程的方式，而不是引入陌生的新事物。Kampa 还将此与更广泛的变革管理联系起来，让领导层、中层管理者和一线员工及早参与，使技术成为业务实际运营的一部分，而不是一个附带项目。

真正的工作从生产环境开始

上线后，Admiral 对待每项智能体变更，无论大小，方式都一样：先作为一个分支通过完整模拟测试套件，再接触客户。Clark 介绍说，发布从 1% 流量开始，实时观察客户满意度和问题解决指标，确认数据稳定后再扩展至 100%。这一周期已从数周缩短至数小时。

这一迭代过程带来了两项突出经验：

• 本地化语言，而不只是翻译文字。 Admiral 最初以英语编写所有提示词和 workflow，发现法国、西班牙和意大利的表现不如英国。后来，他们不再从英语翻译，而是以每个市场的本地语言重新编写提示词，得到的回复更符合当地客户的期望和文化。
• 必须认真对待模拟测试，不能把它当作形式。 Neely 表示，编写能通过少量模拟测试的提示词看似容易，但构建真正能对智能体施压的测试套件，并预先定义清晰的成功标准，才是更难也更重要的工作。Admiral 如今会在每项变更上线前，运行数百至数千次模拟对话。

谈到成果，Kampa 指出，处理时长是最突出的指标：由 AI 主导的对话通常比人工主导的对话更快达成相同结果，部分原因是系统加载时不会出现沉默等待。她还提到，客户满意度（CSAT）和问题解决率通过一轮轮测试与调整，在各个市场逐步提升，而非一次性大幅跃升。

如果你刚开始，可以从中借鉴什么

Neely 给刚开始这项工作的团队的建议是：选择一个范围明确的用例，尽快投入生产，让真实客户对话而非更多上线前测试来发现边缘情况。Clark 补充说，一旦两端的集成（电话系统和内部系统）得到验证，扩展到更多用例的速度会越来越快，因为团队已经知道哪些评估和指标最重要。

Kampa 在结尾提出了更长远的目标：不仅要自动化对话，还要利用同一 AI 层，通过实时转录、下一步最佳行动提示和培训模拟，直接支持人工客服。

正如主持人总结的那样，这场对话贯穿始终的一点是：监管与 AI 并不矛盾。从第 1 天起就在构建中考虑可审计性、一致性和人工升级转接，让 Admiral 的智能体更有规范，而不是更少。

观看完整会议

观看完整会议，包括现场构建演示和观众问答。