DBS：把生成式 AI 放在人工客服身后，而不是前面

DBS 给一线客服官（Customer Service Officer）配的 CSO Assistant，做的是一件表面不起眼的事：客户在电话另一端讲话，系统实时把语音转成文字，同时在银行内部知识库里即时检索出相关条款与答案，把这些内容摆到接线座席的屏幕上。整个过程里，客户听到的仍然是那位人类座席的声音，AI 只在座席这一侧工作。它不接管对话，只把座席原本要自己去翻找的东西提前铺好。

支撑这套做法的，是 DBS 对外披露的几个数字。据 DBS 自己的口径，试点以来转写与方案匹配的准确率接近 100%；全面铺开后，预计能把单通电话的处理时长压缩最多 20%；参与试点的客服官中，接近九成表示这套工具对自己的工作有正面影响。需要立刻标注清楚的是，「接近 100%」是 DBS 的自我报告口径，「最多 20%」是全量铺开后的预期而非已兑现的结果，两者都不宜被搬到别的机构头上当作行业基准。

真正值得读第二遍的信号，藏在这家东南亚最大银行为 AI 选定的位置里。它把生成式 AI 摁在那个要对客户担责的座席身后，而没有让它顶到台前去直接应答客户。市面上更常见的路径是反过来的：先做一个能直接对话的客服机器人，把人力尽量替换掉，用「机器人接管了多少比例的会话」当作成绩。DBS 在零售客服这条线上没有走那条路。

同一家银行在另一条线上做了不同选择，这恰好构成对照。面向企业客户的 DBS Joy 于 2025 年 11 月上线，让企业客户直接与 AI 对话，累计处理超过 12 万次会话，客户满意度提升了 23%。一边把 AI 收在人身后，一边让 AI 直接面客——这是同一套判断在两种互动上给出的两个答案，并不自相矛盾。这条判断线是什么，是这篇分析要拆开的核心。

对 ASEAN 的银行、保险和受监管服务业的数字化与合规负责人来说，DBS 提供的是一份关于「AI 该站在哪一侧」的决策样本，而不止是一个「用了 AI」的案例。它值得抄的地方不在于用了什么模型，而在于它把「放在前面还是后面」当成一个需要论证的产品决策，并且给出了可复核的依据。接下来先拆机制，再拆这条判断线，最后落到一份可直接带走的分级规则和该盯住的信号上。

要判断这套工具值不值得抄，先得看清它到底替座席省掉了什么。一通银行客服电话里，座席的时间大致花在三处：听懂客户在问什么，在多个系统和政策文档里翻找相关信息，以及判断这条信息适不适用于眼前这位客户、并组织成一句得体的答复。这三段里，最耗时又最机械的是中间那段翻找——政策条款散落在不同文档，账户信息分布在不同系统，座席一边要维持对话，一边要在后台切窗口、搜关键词。

CSO Assistant 精确地咬住了这中间一段。实时转写解决第一段的一部分——它让系统「听懂」客户在问什么，从而知道该去检索什么；知识库检索解决中间那段——它当场把相关条款拉到座席眼前，省掉手动搜索。省下来的是检索的时间成本，这也正是「处理时长最多降 20%」这个预期数字的来源：压缩的是翻找环节，而不是对话本身。

关键在于它没有碰第三段。「这条政策适不适用于这位客户」的判断，仍然完整地留在人这一侧。系统把条款递上来，但要不要用、怎么措辞、这位客户的具体情形是否落在条款的适用范围内，由座席拍板。分工由此变得清楚：AI 负责又快又全地把信息取到位，人负责在有责任的环节上做决定。这条分界不是技术能力画的，而是责任归属画的——凡是错了要有人负责的地方，决定权就不交给模型。

这种分工顺带解释了为什么「接近 100% 的准确率」仍不足以让 AI 走到台前。准确率描述的是取信息这段活干得多好，而台前那段活是判断和担责，是另一种性质的工作。一个能把条款检索到位的系统，未必能判断这条条款用在这位有特殊情形的客户身上会不会出错;更未必能承接「我把钱托付给你，你别给我搞错」这层期待。取信息的准确和担责的资格，是两件事。

对想复制的机构，这一段给出的第一个可带走的心智模型是：先把你的业务流程拆成「取信息」和「做判断」两类动作，再只把前一类交给 AI。很多 AI 客服项目之所以翻车，是因为它们没做这道拆解，直接让模型端到端地既取信息又做判断又对客户开口，于是模型在检索环节的一个小误差，会被它自己一路放大成一句错误的、已经说出口的答复。DBS 的做法把误差挡在了「说出口」之前。

任何声称「接近 100%」的系统，值得追问的是剩下那一点点在哪里、以及它出错时会怎样。CSO Assistant 有两个天然的失效面。第一个是转写：银行客户来自不同地区，口音、语速、专业术语、背景噪音都会让语音转文字出错，一旦转错，后续检索就可能顺着错误的关键词去取错误的条款。第二个是检索：知识库本身会过期，政策更新了而文档没跟上，或者同一问题对应多条相近条款，系统可能匹配到形式相关但实质不适用的那一条。

这两个失效面的共同点是：它们都发生在「取信息」环节，而这个环节的输出会先经过座席的眼睛，再决定要不要用。座席听得到客户的真实语气和完整语境，看得出屏幕上弹出来的条款和客户实际问的是不是一回事。当转写把「能不能提前还款」听成「能不能提前还清」，或者检索把一条已作废的费率推上来，座席能当场把它拦下来，用自己对政策的理解修正或忽略。人工在这里是这套系统的最后一道校验层，而非摆设。

把 AI 放在座席身后，本质上是在给这两类几乎必然会发生的错误留一个缓冲带。如果同样的错误发生在一个直接对客户开口的机器人身上，缓冲带就没了——转错的一句话、匹配错的一条政策，会直接变成对客户说出去的答复。在银行场景里，这种错误的代价不是一次糟糕的体验那么简单，它可能是一次合规越界的表述、一个被误导的财务决定，进而是投诉甚至监管问询。错误的性质从「内部可修正」变成了「对外已发生」。

这也是为什么高准确率不能成为「让 AI 直接面客」的通行证。准确率再高，只要不是严格的 100%，剩下的那部分错误落在哪一侧就至关重要。落在座席身后，它是一次被拦下的误检索，代价接近于零；落在客户面前，它是一次已经造成的伤害，代价可能很高且不可逆。同一个模型、同样的错误率，因为站位不同，风险量级完全不同。站位决定了错误的下限。

因此这一段给管理者的判断是具体的：评估一个客服 AI 时，别只看它的平均准确率，要看它剩余错误的落点和可回收性。问三个问题——它出错时错误会不会直接到达客户？到达之前有没有一个有能力也有责任的人能拦下来？如果拦不下来，单次错误的最坏后果有多大、能不能事后补救？DBS 的架构对这三个问题的答案分别是「不会、有、因而可控」。这套问法本身，比任何一个准确率数字都更能预测一个客服 AI 项目会不会在生产环境里出事。

到这里可以给出这个案例里最反直觉、也最容易被效率叙事盖过的一点：DBS 把 AI 收在座席身后，护住的首先不是效率，而是客户对某个具体的人的托付。零售银行做的是一门讲人情的生意——客户愿意把钱、把账户里那些让自己焦虑的麻烦，交给一个能听懂自己、能为自己负责的人。这份愿意，是银行真正的资产，也是它在同质化的利率和产品之外还能留住客户的东西。

一旦让 AI 直接对客户开口，受损的就不只是单通电话的质量。客户对话的对象从一个能担责的人，变成一个会一本正经说错话、且无人为这句话负责的系统。就算系统九成九的时候都对，那出错的一次，伤的也不仅是这次咨询的结果，还有客户「我可以把事情托付给你们」这层底层信任。信任的特点是建起来慢、塌下去快，而且一旦客户开始怀疑「电话那头到底是不是一个会为我负责的人」，这种怀疑会外溢到这家银行的其他所有服务上。

这解释了前面那个看似矛盾的准确率现象的深层原因。转写准确率接近 100%，仍然顶替不了客户想面对的那个人，因为客户要的从来是一个正确答案加上一个为这个答案负责的对象，而不止是答案本身。AI 能提供前者，提供不了后者。把它放到台前，等于用一个能给出正确答案但无法承接托付的东西，去替换一个两者都能给的人——在标准答案容易、但情分要紧的互动里，这是一笔亏本的替换。

值得强调的是,这个判断有它成立的条件,不是放之四海皆准的铁律。它成立于「这类互动里客户在意的托付成分很高」这个前提。零售银行客服里,客户往往带着焦虑、带着对自己财务处境的敏感,这类互动的情分权重高,所以 AI 该退到人身后。换一个前提,结论就会翻转——这正是下一段 DBS Joy 要展示的。判断这条线该画在哪,取决于具体互动里「答对」和「被负责地对待」这两种需求各占多重。

对管理者来说,这一段的take-home是一句需要在立项前就想清楚的问题:在你要上 AI 的这个环节里,客户购买的到底是一个正确结论,还是一段有人为其负责的关系?如果是前者,AI 可以往前站;如果是后者,把它往后收。很多机构在客服 AI 上踩坑,是因为它们默认答案永远是「正确结论」,于是理直气壮地用机器人替换人工,直到客户用流失投票,才发现自己卖的其实是关系。先答对这个问题,再决定 AI 的站位。

如果 DBS 的逻辑真是「AI 一律退到人身后」,那 DBS Joy 就成了反例。但它并非反例——它是同一条判断线在另一种互动上给出的另一个答案。面向企业客户的 DBS Joy 直接让客户与 AI 对话,2025 年 11 月上线以来处理超过 12 万次会话,客户满意度不降反升,提高了 23%。同一家银行,一边把 AI 收在座席身后,一边把 AI 推到企业客户面前,两个决定并存且都拿出了正向数据。

差别在互动的性质。企业客户查一笔交易状态、问一个账户权限、办一件流程标准化的事务,这类互动更接近「使用一个工具」——客户要的是快、准、随时可用,而不是一段被人情呵护的关系。在这里,让 AI 直接应答反而更契合需求:它 24 小时在线、响应即时、不需要排队等一个人类座席。满意度提升 23% 这个数字之所以能成立,正是因为这类查询的情分权重本来就低,把它交给 AI,客户得到的是更好的工具体验,而没有失去什么值得留恋的东西。

把两条线并排看,DBS 实际上在用行动定义一条决策规则:互动里的情分权重越高、说错一句话的关系代价越大,就越要把 AI 收到人身后;互动越接近查个数、办一件标准事、情分权重越低,就越可以让 AI 直接面对客户。零售客服偏前一端,企业事务查询偏后一端,于是同一家银行给了它们相反的站位。这条规则从「这段互动到底在卖什么」推出来——两条线用的很可能是相近的底层能力——而非从技术能力推出来。

这个对照对复制者尤其有价值,因为它把一个容易被误解的问题纠正了。常见的误解是把「要不要让 AI 面客」当成一个全公司统一的技术成熟度问题:等模型够好了,就全线上 AI。DBS 的两条线证明这是个错误的框法。它是一个逐互动判断的产品决策,而不是一个随时间线性推进的技术档位——同一时刻、同样的技术,不同互动就该有不同站位。管理者要做的是给每一类互动单独判一次站位,而不是等一个全局的「可以了」。

需要标注的是,DBS Joy 的 23% 和零售线的数字来自不同产品、不同客群,不能直接相加或互证,也不宜外推成「企业场景 AI 都该面客、零售场景都该退后」的一般结论。它们共同证明的只有一件事:站位应当随互动性质变化,而这家银行显然是按互动来判的,不是按技术档位来判的。把这条对照当成一面镜子照自己的业务——你手上哪些互动像零售客服,哪些像企业查询——比记住这两个百分比有用得多。

「先测试再铺开」是句正确的废话,几乎没有机构会公开反对它。DBS 值得抄的是它把「铺开」这个动作拆成了几道能真正卡住放量的关,而不是这句口号。一套 AI 客服工具从试点走向全量,中间最危险的是那类指标好看、单次却代价很高的边缘失败,而不是那些一眼能看出的大错:一条被误配的过期政策、一句在合规上刚好越界的表述。这类错误在平均准确率里几乎看不见,却足以酿成投诉或监管问题。

把 AI 只放在取信息一侧、把开口权留给人,本身就是第一道关——它给上述这类错误预留了一个人工兜底的缓冲。但架构上的克制只是起点,治理的功夫在于把「达到什么条件才放量」写死。据现有公开信息,DBS 用试点数据(准确率、座席正面反馈)作为铺开的前置条件,这是对的方向;可以进一步明确、也建议复制者补齐的,是把这套前置条件做成一张可执行的清单,而不是一次笼统的「数据不错就上」。

这张清单对想照做的机构至少应包含三样东西。第一,铺开前锁定几个指标的阈值——转写准确率、方案匹配率、人工升级率——并规定达不到阈值就不放量,把「好看」量化成「过线」。第二,写明由谁签字放行:AI 客服跨了合规、体验和运营,放量决定不该由单个部门自己拍,要有一个明确的、跨职能的签字人。第三,在试点和全量之间设一个中间检查点,专门盯那些「指标合格但一旦出错代价很高」的边缘案例有没有在扩大样本后露头。

这三样东西的作用,是把「先数据后铺开」从一句态度,变成一道真能拦住事故的闸门。区别很实在:没有量化阈值,「数据不错」就会在放量压力下被解释成「差不多可以了」;没有指定签字人,出了事就会变成部门间互相指认;没有中间检查点,试点样本里没出现的边缘案例,会在全量的大样本里第一次出现,而那时已经对着真实客户了。三道关各自堵住一种「口号化」的漏法。

对 ASEAN 受监管行业的落地负责人,这一段是最能直接搬进立项文档的部分。它不依赖 DBS 用了什么模型,也不依赖那几个具体百分比,它是一套流程纪律:定阈值、定签字人、定中间检查点。把这三样写进你自己的 AI 客服铺开方案,你就复制了 DBS 真正难复制的那部分:难复制的从来是不让「测试通过」这四个字被稀释的组织约束,而非技术本身。

对这个案例保持诚实,就得把它没讲清的部分也摆出来。DBS 公开披露了转写、检索、准确率、满意度这些正向信息,但对几个关键的边界问题,公开细节有限。何时必须把电话从 AI 辅助转为纯人工处理?当座席采纳了系统推来的一条政策、而这条政策后来被证明用错了,责任在座席还是在提供工具的一方?系统给出误导性建议时,追责链条怎么走?这些问题目前没有充分的公开答案,因此这套架构在最坏情况下的稳固程度,仍需更多验证。

这不是吹毛求疵,因为整套设计的安全性恰恰押在这条边界上。前面说 AI 放在座席身后是安全的,前提是座席真的会审阅、有能力审阅、也有动力审阅系统推来的信息。如果实际运行中,座席在效率考核的压力下倾向于直接采纳系统建议、把审阅退化成走过场,那么「人在环里」就名存实亡,人工兜底这道关会悄悄失效。工具越准、越省事,座席越容易放松警惕——这是一个和准确率提升方向相反的隐性风险,准确率越高,反而越可能诱发过度依赖。

处理时长「最多降 20%」这个目标,和审阅质量之间也存在张力。降时长的压力会激励座席更快挂断、更少复核,而复核恰恰是这套架构安全性的来源。如果考核只奖励快、不惩罚该拦没拦下来的错误,那么效率指标会系统性地侵蚀安全边界。这里没有证据说 DBS 出了这个问题,但任何复制者都会面对同一个结构性张力:同一套系统,考核口径偏一点,就可能从「人机协作」滑向「人给机器背书」。

因此对这套架构的正确态度是审慎乐观,而不是照单全收。它的机制设计是对的——把担责的判断留给人、给误差留缓冲——但机制能不能在日常运营里保持有效,取决于两件公开信息里看不到的事:座席审阅是不是真实发生的,以及考核有没有在暗中鼓励座席跳过审阅。复制这套架构的机构,必须把这两件事纳入自己的监控,否则抄来的只是一个安全的外壳,内里可能已经空了。

给管理者的具体动作是:除了盯准确率和时长这些正向指标,单独建立一组「审阅是否真实发生」的观测——比如座席对系统建议的修改率或否决率。如果这个比率长期趋近于零,该被当成座席可能已经停止独立判断的警报,而不是系统完美的证据。一个健康的人机协作系统里,人应该经常性地否决或修正机器;当人不再否决机器,人就已经不在环里了。这条观测,是验证那条未公开边界是否真实成立的替代手段。

把前面几段收拢,可以得到一条能直接用的决策规则,它比「AI 要不要面客」这个笼统问题精确得多。第一步,把你业务里所有面向客户的互动,按一个维度排序:这段互动里,客户在意的「被一个能负责的人妥善对待」有多重,相对于「拿到一个正确结果」有多重。前者权重高的,归为关系型互动;后者权重高的,归为事务型互动。这个维度不是感觉,它可以用具体问题逼近——说错一句话会不会动摇客户对机构的整体信任?客户来的时候是带着焦虑还是带着一个明确的待办?出错后能不能靠一句道歉和一次更正就抹平?

第二步,给两类互动配不同的 AI 站位。关系型互动——零售客户的账户纠纷、贷款焦虑、投诉——把 AI 收到座席身后,让它做实时转写和知识库检索这类取信息的活,把判断和开口留给能担责的人。事务型互动——企业客户查交易状态、办标准化流程、问权限设置——可以让 AI 直接面客,因为客户要的是随时可用的工具体验,而这类互动里几乎没有情分需要呵护。DBS 的零售线和 DBS Joy,正好是这两类的两个落点。

这条规则的价值在于它把一个被普遍问错的问题纠正了过来。多数机构问的是「我们的 AI 够不够好到可以面客」,把决定权交给一个技术成熟度判断;正确的问法是「这一类互动的情分权重高不高」,把决定权交给一个产品性质判断。前一种问法会导致全线激进或全线保守;后一种问法会导致同一家机构里,有的互动 AI 在前、有的互动 AI 在后,而这恰恰是 DBS 展示出来的成熟形态。技术档位是全公司共享的,情分权重是逐互动不同的,所以站位必须逐互动判。

要注意这条规则是一条连续谱,而非非黑即白的两个桶,大量互动落在中间地带。一个务实的处理是给中间地带设一个默认方向:拿不准的,先归为关系型,把 AI 放在人身后。理由是这个方向的错误更便宜——把一个本可以让 AI 面客的事务型互动错放到人身后,损失的只是一点效率;把一个关系型互动错放到 AI 面前,损失的可能是客户的信任,而后者贵得多且不可逆。在不确定时,让站位偏保守一侧,是符合风险不对称性的选择。

这条规则也划出了它自己的适用边界。它适用于「答对相对容易、但被负责地对待很重要」的受监管服务业客服场景——银行、保险、以及类似的高信任行业。在那些答对本身就极难、或者根本没有情分成分的场景里(比如纯技术工单、纯信息查询),这条以情分权重为轴的规则就不再是主要矛盾,该换别的轴来判。带走这条规则时,连同它的适用范围一起带走,才不会把一个针对信任型互动的判断,误用到不讲信任的场景里。

按情分权重分级不是一劳永逸的静态划分,因为「一类互动里有多少情分要守」本身会随时间移动。今天客户还想要一个人来处理的某类咨询,几年后可能因为习惯变化、因为 AI 体验变好,变得像使用工具一样自然。所以这条决策规则真正完整的用法,是给它配一个可观察的信号,用信号——而非感觉——来告诉你那条分级线该往哪一边挪。DBS Joy 恰好演示了这个信号长什么样。

这个信号就是分类型的客户满意度曲线。触发把某类互动从「AI 在人后」挪到「AI 可面客」的条件是具体的:当这类咨询在 AI 直接处理下的满意度,持续追平甚至超过人工处理时的满意度,就说明客户对这类互动的情分需求已经降到可以放手的程度——DBS Joy 那 23% 的满意度提升,就是企业事务查询这类互动已经越过这个临界点的证据。反过来,反向信号同样明确:如果某类互动交给 AI 面客后,满意度回落,或者人工升级率、投诉率抬头,那就是客户在用行为告诉你情分需求还在,该把这类互动的站位收回到人身后。

把触发条件和反向信号成对地盯住,这条规则就从一次性的判断,变成一个能持续自我校正的机制。这一点对管理者尤其重要,因为静态划分最大的风险是刻舟求剑——按今天的情分权重画好线,然后随着客户习惯变化,这条线慢慢画错了却没人发现。满意度曲线让这条线能动:客户在哪类互动上开始接受 AI,曲线会先告诉你;客户在哪类互动上还离不开人,曲线也会先告诉你。你要做的是持续读这条曲线,并在它明确翻转时才动站位,而不是被一次波动带着走。

需要克制的是,别把这个信号绝对化。满意度是一个滞后且会被短期因素干扰的指标,一两个季度的波动不足以支撑挪线的决定,只有持续、跨足够样本的趋势才算数;而且满意度追平不等于风险追平——某类互动即使满意度上来了,只要它单次出错的合规代价依然很高,就仍有理由让 AI 留在人身后。所以这个信号是挪线的必要条件,不是充分条件:它能提示「客户已经准备好了」,但「风险是否也已经可控」还得单独判一次。两个判断都过,才动站位。

对 ASEAN 的同行,这一整套东西可以压成三句可执行的话。先按情分权重把你的客户互动分成关系型和事务型两类,重的把 AI 收到座席身后、只让它取信息,轻的放手让 AI 面客。再给这条分级线配一组分类型满意度和人工升级率的观测,让它随客户习惯变化而能移动。最后在每次准备挪线时,除了看满意度趋势,单独再问一次这类互动出错的最坏代价能不能承受。DBS 没有给出一个可以照抄的终态,它给出的是一套可以照着运行的判断和校正流程——而在客户习惯持续变化的市场里,一套会自我校正的流程,比任何一个当下的正确站位都更值钱。