开篇：条款咨询不是"AI 会不会答"的知识题

保险公司做 AI 客服，最先撞上的墙不是技术，是边界。技术选型可以换，边界画错了却会一直错下去。
客户问"我这个情况到底赔不赔""为什么这个药不在保障范围内""两张保单能不能叠加赔付"——这些问题在语义上和"保单什么时候到期"没有本质差别，都是中文句子、都可能命中某份条款文档。但两者在责任上完全不同：前者一旦说错，涉及的是金融合约的达成与客户权益；后者说错，最多是一次体验瑕疵。
很多团队把这件事当成知识覆盖率的提升题，做法是不断往知识库塞文档、调检索、换更大的模型。这条路走到某个点就推不动了，因为真正的障碍在于回答范围的责任归属。这是一个责任划分问题，不是知识问题。
而这件事，监管已经把它写成了条款。《国家金融监督管理总局关于银行业保险业人工智能安全开发应用的指导意见》明确：涉及承保理赔等与客户利益直接相关、直接影响金融合约达成的生成式人工智能场景应用，应被视为高风险应用。
文件同时写明：可解释性不足的人工智能技术在高风险场景应用时，仅能作为辅助工具，应由人工进行最终决策。模型应用于涉及客户权益或有实质性财务影响的关键决策时，须设置人工复核节点，完整保留原始数据、推理路径及阈值触发记录。
换句话说，"人工复核"在这类场景里属于设计前提，没有可选项的余地。下面这套方法因此不从"上什么模型"开始，而从"先分级"开始。

一、条款咨询的四级处理：先分清"能答"和"不能答"

分级不能按问题长短看，也不能按情绪强弱看。真正决定处理方式的是四个信号，按四个信号判级：
第一，答案在官方条款里有没有原文。是"条款第几条怎么写的"，还是"这个条款在他这个案子里怎么用"——后者已经不是检索题。
第二，是否需要读取客户个案数据。查询进度要读保单状态，但读数据本身不产生判断；一旦要基于个案数据得出结论，性质就变了。
第三，是否会产生责任承诺。赔付金额、责任认定、条款适用性判定，这三类都是承诺，不是说明。
第四，客户身份与权限是否足以回答。企业团险的查询权限和个人保单不同，代理人身份与投保人身份可看的内容也不同。
按这四个信号，条款咨询可以分成四级。一级可直接答，二级依据可查地答，三级按固定口径答，四级必须停并转人。
级别判断信号典型问题形态AI 的处理动作停下来交给谁常见返工点
一级·可直接答条款有原文，不读个案数据，无责任承诺等待期多久、犹豫期怎么算、保障范围包含哪些依据知识库直答，附条款出处不需要转出答案没挂版本，条款换版后旧说法仍在用
二级·依据可查地答需要读客户业务系统数据才能答保单是否生效、理赔进度到哪一步、材料要交哪些校验身份后调系统取数，返回结果与出处取数失败或字段缺失时转人工接口权限没配全，取数失败率高
三级·按固定口径答条款有明确规则，但表述容易产生歧义保障版本之间的区别、某项责任是否写入条款用固定话术或原文引用作答，不改写客户追问适用性时立即转出口径没锁死，模型自由发挥
四级·必须停并转人会形成责任承诺，或涉及客户权益判断能不能赔、赔多少、这个事故属不属于保险责任只做信息收集与引导，不做判断，带上下文转出由持牌专业人员按流程处理转出时上下文丢失，客户要复述一遍
这张表的作用是让"能答"和"不能答"有一个共同的尺子。监管对这类应用的要求是完善人机协同的业务管理流程、科学设定人工智能的功能边界、系统和数据权限——落到客服系统上，对应的就是这张分级表：每一级的功能边界写清楚，每一级的取数权限画清楚。
需要提前说清的一点：分级不是一次性的。同一个问题在客户追问第二遍、第三遍之后，级别会上移——第一次问"等待期多久"是一级，追问"那我这个手术算不算等待期内"就是四级。系统要能识别这种上移，而不是因为前两轮答得顺就继续往下答。

在车险这类高频条款场景里，行业里已有做法把意图理解细化为场景标签，再按标签决定处理路径——保单选型、承保咨询、批改操作各自走不同的链路。形态不同，但底层逻辑与这张分级表一致：先定级，再定动作。

在线-机器人.jpg

二、第一步：把条款类知识变成可引用、可授权、可运营的知识底座

分级表要能落地，前提是知识底座先立得住。这一层做不好，后面三级的差异配置都无从谈起。

2.1 这一步的落地动作

第一件事是导原始文档，而不是先拆 FAQ。条款文档、产品说明书、费率与责任摘要、理赔材料清单、服务流程文档，先按原样进库，保持文档的完整性。FAQ 是二次加工产物，一旦先拆 FAQ，条款的上下文、章节层级和限定条件就丢了，后面想回溯原文已经没有原文可以回。
进库后走知识解析、语义切片、向量检索与大模型问答的链路，形成的知识来源是共享的——在线客服 Agent、电话 Agent、坐席辅助 Agent 与人工坐席读的是同一套知识，不是各维护一份。这一点在保险场景里尤其重要，因为"AI 说的"和"坐席说的"不一致，是最容易引发争议的形态。
接着按条款版本、产品线、生效日期建知识分类，并给条款挂上到期日期与生命周期状态。条款是有保质期的文档，没有到期字段的知识库，本质上是一个不断积累过期信息的知识库。
然后配权限：管理员、可见范围、分享、下载、问答权限分级。最后把命中分析与知识缺口接进运营回路——客户反复问但库里答不好的问题，要能被看见，并形成"问题到补知识"的闭环。

2.2 客户侧要提前准备什么

知识底座的建设有一半工作量在客户侧。这部分不提前准备，项目一定会返工，而且返工点大多集中在下面四件事上：
一是条款原文的归属与版本。哪一份是当前生效版、谁有权确认、旧版本怎么归档，必须有人拍板。这个过程不能由系统代劳，因为系统无法判断两份文件的效力先后。
二是术语口径表。条款的专业表述和面向客户的口语解释要分开维护，二者不得混写。比如条款里写"保险责任期间"，客户听到的应该是"能保到什么时候"，但这句话不能反向污染条款原文。
三是知识更新的责任人与触发条件。产品上线、费率调整、政策变化，各自对应谁在多久之内更新知识库。
四是个人信息边界。监管明确，姓名、身份证号、手机号、银行卡号等个人信息和隐私数据不得用于生成式人工智能模型训练和优化。客户侧要先划清：哪些字段可以进知识、哪些只能走接口实时查询、哪些根本不进系统。

2.3 怎么算跑通

知识底座是否立住，看三条可验证的标准。这三条都能在验收阶段逐项检查，不依赖主观判断：
任一条款类答案都能回指到具体文档与版本，不会只有一个答案、没有出处。权限生效也可被验证，不同角色登录后可见的知识范围确实不同。条款更新后，旧版本能被识别为过期，而不会被继续检索命中。

2.4 技术前提与边界

可导入的文档格式、单文件大小上限这类参数按项目配置确认，不一一列举。要明确的是能力边界：知识库负责检索与运营，不负责自动补全盲区。这一点在评估阶段必须说清楚，否则上线后第一次踩到知识盲区，就会演变成对整个项目的质疑。
监管对这类应用的要求是推进知识工程建设、建立从知识创建、审核、发布、更新到归档的全流程管理规范——落到客服系统上，对应的就是知识分类、生命周期与权限设计这三件事。换句话说，知识库承载的是一套需要持续运营的制度，上传文档只是其中一步。

三、第二步：用知识图谱把"条款"变成可推理的关联网络

二级和三级问题的难点，在于条款咨询往往要跨好几份文档才能拼出答案。这不是检索能力不足，而是知识本身的组织方式问题。
举个结构上很典型的例子：客户问"等待期内确诊的疾病，后续治疗费用能不能报"。这个问题要拼的是至少三份信息——产品条款里的等待期定义、该疾病的分类归属、以及免责条款里的例外情形。传统检索把文档切片后按语义相似度召回，很可能只召回其中一段，另外两段因为措辞不同而落选。答案因此残缺，而残缺的答案比答不出更危险：客户会默认这就是完整答案。
知识图谱处理的就是这类问题。行业里通用的做法是：把知识从文档中抽成实体、关系与属性三类要素，以"实体 A—关系—实体 B"的三元组为基本表达单位，检索时沿着关系链路走，从而支持跨文档、多跳的关联。落到保险条款场景，实体与关系的设计大体长这样：
图谱要素保险条款场景的取值解决什么不解决什么
实体·产品具体保险产品、保障版本定位到哪一份产品不判断产品是否适合客户
实体·条款保险责任、责任免除、等待期、犹豫期、理赔条件定位到具体条款单元不判定条款在本案是否适用
实体·风险对象疾病、意外类型、医疗项目、药品把客户的表述映射到条款用词不做医学判断
关系·产品到属性产品名称 ↔ 犹豫期 / 等待期 / 保险责任一次召回产品的整组关键属性不比较产品优劣
关系·条款到例外责任 ↔ 除外责任 ↔ 例外情形避免只召回到正面条款而漏掉例外不替代人工认定责任
这个设计不是凭空推的。行业公开信息里，已有保险公司与 AI 厂商共建的智能知识库，做法就是从保险条款、产品文档等非结构化数据中自动解析，抽取产品名称及与之关联的犹豫期、等待期、保险责任等产品属性，自动关联形成产品知识图谱，用于回答保障内容、产品比较、符合要求的产品有哪些这类问题。
也有互联网保险科技平台把图谱范围扩到医学术语、药品知识、疾病知识与保险条款解析。这类平台的覆盖范围延伸到智能问答、客服、理赔、核保几个环节，说明图谱的边界取决于业务要问什么。
但知识图谱的代价必须一并说清，否则就是单方面推销。它的构建需要额外的抽取与维护成本，实体关系抽取本身存在误差风险，查询链路更长、对工程能力的要求更高。更关键的是：检索精度提升的同时，首次构建与后续变更的维护投入明显高于纯向量方案，而实体关系怎么设计，依赖业务方持续参与——这不是一个可以完全交给技术的活。
所以适用判断很直接：要跨文档拼装、要沿关系推理，才值得上图谱。只查单条事实、知识之间没有交叉关联的场景，纯检索更划算。给每一类问题都套图谱，是把成本花在不产生差异的地方。
最后要收口一句：图谱解决的是找得准，不是说得对。它能保证相关的条款被一起召回，但不能保证召回来的条款被正确表述、也没法保证限定条件没被漏掉。表述的准确性，要靠下一步的锁口径配置来保证。

四、第三步：关键口径锁死——政策、规则、金额不交给模型自由改写

图谱把材料找齐了，接下来要解决的是"怎么说"。条款咨询里，答案可以被分成两类，处理方式必须分开。
一类是可自然生成的：条款的结构说明、流程指引、材料清单、术语解释。这类内容即使措辞有变化，语义也不会走样，交给模型组织语言反而更自然。
另一类是必须锁口径的：政策、规则和金额。这类内容一旦措辞偏移，含义就变了。"原则上可以报销"和"符合条件可以报销"，在客户听来是同一句话，但在后续争议里是完全不同的两个承诺。
对后者，保险场景里最关键的是把表述锁住。合力亿捷的在在线客服 Agent 提供的处理方式是关键回答可控、内容依据可追溯。企业可直接导入原始知识文档，对于政策、规则和金额等关键内容，可配置原文引用、精准答案或固定话术三种方式，减少模型自由改写，使回答依据和内容来源可追溯。
三种方式对应的表述类型不同，选错方式反而会增加风险：
条款内容类型配置方式落地动作边界
条款原文、免责表述原文引用直接引用条款文本并标注出处原文晦涩时客户可能不理解，需配合口语解释
保障范围、等待期、犹豫期精准答案预置标准答案，不交由模型改写答案需随条款版本同步更新
金额、期限、比例类表述固定话术完全固定句式，变量由系统填充变量来源必须是客户业务系统，不由模型推断
流程指引、材料清单自然生成由模型组织语言，依据仍挂知识出处措辞可调，但条目不得增删
这里要强调一个容易被写偏的点：锁口径做的是减少模型自由改写，而不是取消模型。把高频关键问题全部写成固定话术，看起来最安全，实际会退化成规则应答——客户换一种问法就答不出，复杂追问也接不住。正确的做法是让模型负责理解与组织，让配置负责约束关键表述。
监管对这类应用的要求中，有一条是对人工智能生成内容进行显著标识并向金融消费者主动说明——落到客服系统上，对应的就是：需要明确告知客户当前是 AI 在应答，并在必要时说明答案的依据来源。它属于服务流程里的一个固定环节，而不只是一句免责声明。

五、第四步：让 AI 干活的那一段——查得到、引导得了、办得完

一级到三级的问题里，有价值的部分是二级：客户真正想要的是"我的这个办到哪一步了"，而不是一段条款解释。这一段能不能做好，决定 AI 客服是"答问机器"还是有办事能力的入口。

5.1 这一步的落地动作

先采集并校验客户身份与业务信息。保单号、手机号、证件号后 8 位这类字段由客户侧确定，系统只按配置收集，不做额外推断。
校验通过后调客户自己的业务系统，取回保单状态、材料清单、进度节点、可办理事项这类结果。注意这里是"调客户系统"，不是"让 AI 猜"——AI 的价值在于把客户的模糊表述转成系统能识别的查询参数，并把返回结果翻译成客户能听懂的话。
对可办理事项，校验通过后自动建单或生成工单草稿并推送回客户系统，用同一个工单号贯穿全流程。客户后续再问，凭同一个工单号就能定位。
如果这件事无法独立处理，转人工时要携带已采集的字段与完整对话上下文，不让客户复述第二遍。这一条看似是体验细节，实际是三级到四级转换时最容易掉链子的地方：如果转过去之后坐席要从头问一遍，客户对整套 AI 服务的信任会在那一刻归零。

5.2 客户侧要提前准备什么

可查询的字段清单与接口权限要提前定。谁授权、按什么频率调用、数据是单向还是双向同步，这三项没谈定就不要开工。
办理类动作的前置条件要写清楚。哪些必须本人确认、哪些必须留痕、哪些动作只能生成草稿由人工提交，这三类要逐项列明。
人工侧接收转办的技能组与工单模板要事先配好。这项不做，转过去的工单没有正确路由，客户还是在等，等于转了个空。

5.3 怎么算跑通

查询类问题不落人工也能给出可核对的结果；建单成功率、字段完整率可以统计出来；转人工时上下文与已采信息不丢失。这三条都是可量化、可验收的，不依赖主观评价。

5.4 技术前提与边界

要提醒一句：有 API 不等于无需开发即可接通。鉴权方式、字段映射、调用频率、同步时效、第三方系统的权限范围，都要逐项确认。业务执行能力依赖流程、工具与接口配置的实际完成度。

5.5 一轮对话长什么样

下面这张表是一次典型的条款咨询对话展开方式。它覆盖了前面说的四条分支，逐轮对应 AI 在每一轮分别做了什么、又在哪里停下来：
轮次用户说AI 做什么收到什么字段分支判断
1我这个保单还有效吗请求核验身份保单号或手机号可直接答 → 进入取数
2（提供手机号）调用客户业务系统校验保单状态、生效与终止日期需读数据后答 → 返回结果并附出处
3那理赔要交哪些材料依据条款与理赔清单作答材料清单条目按固定口径答 → 用预置答案，不改写
4我这个情况能赔多少停止自行作答保留已采集字段与上下文触发停止并转出 → 带上下文转人工
5（人工介入后）生成工单草稿与摘要工单号、问题类型、已办事项工单号贯穿，后续凭号追踪

5.6 示例里刻意没做的事

这张表里有几件事是故意不做的。它们比做了什么更能说明边界在哪里：
没让 AI 判断"这个事故属不属于保险责任"；没让 AI 给出"能赔多少"；没让 AI 解释"哪一条条款在这种情况下适用"。也没有在资料不全时让 AI 替客户"先受理"。
这些都属于专业判断。AI 在这类场景里只做引导与服务动作——收集信息、取回数据、解释流程、生成工单，把判断留给客户侧的人工与业务流程。把这条线守住，AI 客服的价值反而更清楚：它承接的是量的部分，专业判断仍然由有资质的人完成。

六、第五步：停下来之后——人工复核怎么被增强，责任边界怎么留下

第四步的终点是"转出"，第五步要解决的是转出去之后发生什么。这也是整篇里监管依据最硬的一段。

6.1 监管要的是什么

监管对这类应用的要求很具体：在高风险应用关键环节建立人工监督和干预机制，明确紧急停用及模型退出条件，建立备用系统或人工替代流程。模型应用于涉及客户权益或有实质性财务影响的关键决策时，须设置人工复核节点，完整保留原始数据、推理路径及阈值触发记录，确保责任可追溯。
注意几个要点：监管要求的是一个节点，不是象征性看一眼。节点要有明确的触发条件、明确的处理人、明确的结果记录。而且要求保留的不只是最终答案，还有原始数据、推理路径和阈值触发记录，也就是要能回答"AI 当时看到了什么、按什么链路推出来、哪一步触发了复核"。
紧急停用与人工替代流程同样不是形式条款。模型升级、知识大规模变更、出现集中性错误回答时，要有能力切回人工，这个能力必须事先建好，不能等出事再想办法。

6.2 人工侧怎么被增强

复核不是把人工侧变成体力活。实际上复核环节被增强得越充分，节点才能真正运转起来，而不是变成积压。
在合力亿捷的坐席辅助 Agent 里，人工侧获得的支持包括：识别客户意图、推荐话术、知识与标准服务流程，提供客户画像与历史沟通摘要，以及风险提示。会话结束后，自动生成会话摘要、服务小结、客户标签、质检要点与工单草稿。对于复杂问题，人工处理完还可以按流程把后续接待重新交回 Agent。
这里的关键是：给的是建议和草稿，不是决定。坐席辅助为人工提供建议和草稿，复杂判断、敏感决策和最终服务动作仍由人工及企业流程控制。这个定位必须写清楚，因为它划定的正是监管所说"作为辅助工具、由人工进行最终决策"的那条线。
行业公开信息里也能看到图谱与人工组合的形态：客户咨询"多张保单如何叠加赔付""院外特效药能否理赔"这类复杂问题时，人工坐席借助知识图谱关联到对应保险条款，把原本需要跨系统查询的流程压缩为即时响应。这个形态与本篇主线高度吻合——图谱把材料找齐，人工做判断并对外负责。

6.3 复盘需要什么材料

复核节点要留痕，留痕的内容决定了后续能不能复盘。至少要能回答四个问题：AI 当时给出的建议是什么；依据的是哪一份知识、哪个版本；人工是否改动了结果、改成了什么；最终对外答复由谁确认。
质检与 VOC 在这个环节是回流的出口。通过录音转写、在线会话分析、规则与大模型质检，可以识别出错误回答、知识缺口与流程断点，再把这些结果反哺回知识库与流程配置。需要说明的是，AI 质检结果不能替代合规审核和人工复核——它是发现问题的工具，不是做结论的工具。

6.4 各环节的分工落点

环节Agent 接住的是哪一段人工接住的是哪一段留痕什么
身份校验收集与校验客户身份、业务字段无采集字段与校验结果
条款说明原文引用、精准答案、固定话术客户对适用性追问后的解释命中的条款与版本
数据查询调客户系统取回状态与进度取数失败或字段异常时的处理调用记录与返回结果
办理动作校验后建单、生成工单草稿需判断或需本人确认的环节工单号与动作记录
复核节点提供建议、话术、风险提示、草稿最终判断与对外答复原始数据、推理路径、触发记录、改动内容
这张表要表达的是同一个意思：判断类事项全部转人，AI 只做引导与服务动作。转出去之后，责任通过留痕被固定下来。

七、案例：保险与相近行业已经这样做的形态

以下是合力亿捷服务过的保险及相关场景的形态整理。案例主体按约定匿名，只保留细分业务特征；未成交或仅方案交流的条目，统一表述为"服务过这类场景"。

7.1 某普惠健康保障平台

形态是普惠险集中上线期的高频咨询。投保条件、理赔材料、保障范围、材料提交方式、到账进度集中涌入，咨询量呈脉冲式上升，人工产能很难跟着一起放大。
落地路径是让智能客服 Agent 承接标准问题并匹配官方知识库。理赔材料、投保条件、保障范围这类问题给即时回答和操作指引；超范围问题转人工或生成工单；人工侧由坐席辅助实时推荐知识点和标准话术。
这个案例证明的是"前端分流 + 后端人工 + 知识运营"这条人机协同形态。三者缺一，前端分流出来的问题就会堆回人工侧。
环节原来的处理方式设计后的处理方式
标准咨询承接集中上线期咨询量与人工产能不匹配AI 承接标准问题并匹配官方知识库
保障范围解释依赖坐席个人经验与查找依据知识库给出带出处的回答
超范围问题客户在人工排队中等待转人工或生成工单，按模板路由
坐席应答支持坐席自行查找知识点坐席辅助实时推荐知识点与标准话术
知识更新更新分散、口径不一致知识运营持续更新，AI 与坐席共享来源
上表为改造目标与路径设计，不代表已经实现的效果。具体口径以项目实际配置与客户侧业务规则为准，本节不提供量化成效声明。

7.2 某保险经纪与代理场景

一类形态是来华留学生保险服务：投保流程、保费支付、生效状态、理赔规则、垫付流程都属于高频咨询，且存在明显的时差与夜间咨询需求。原有夜间轮班坐席仍难完全覆盖。
另一类形态是车险出单类的群协同：业务群数量上百，前台人手有限，出单、批改、咨询混在群里。这类客户通常已有 400 号码和客服系统，明确不希望一线登录两套系统。
环节原来的处理方式设计后的处理方式
夜间与跨时区咨询轮班坐席覆盖，仍存在空档AI 承接标准咨询，异常情况转人工
投保与生效状态查询坐席反复查台账或系统校验身份后调业务系统返回状态
群内出单协同前台在多个群之间人工跟单群助手承接标准动作，异常转人工
系统使用一线需登录两套系统在原有系统上扩展，不改变一线习惯
上表为改造目标与路径设计，不代表已经实现的效果。具体口径以项目实际配置与客户侧业务规则为准，本节不提供量化成效声明。

7.3 某保险科技平台场景

一类是企业团体健康险的理赔查询与催办。客户要先提供手机号、案件 ID、证件号后 8 位中的信息，系统校验后再调客户业务系统，返回案件状态、预计完成时间、医院要求、理赔资料、保障内容。这个形态与第五章"查得到"最贴合，也最能说明 AI 取数必须依赖客户侧系统配合。
另一类是健康险保障卡咨询：投保流程、保障版本区别、条款说明、问诊购药责任。复杂问题引导客户自助查询后转人工跟进。
环节原来的处理方式设计后的处理方式
案件状态查询客户反复问、人工反复查客户自助查询，AI 校验后调系统返回
理赔催办依赖人工记录与口头跟进生成工单并保留可追踪编号
保障版本区别坐席凭记忆解释，口径易偏用预置答案解释，不改写
问诊购药责任混在人工队列里处理标准部分 AI 答，复杂部分转人工
上表为改造目标与路径设计，不代表已经实现的效果。具体口径以项目实际配置与客户侧业务规则为准，本节不提供量化成效声明。

7.4 保险售后场景

一类是理赔补资料外呼：需要通话录音、接听情况查询，节假日还要转接手机。另一类是车险事故服务：群助手、语音机器人、外呼与质检组合使用，把事故报案、资料补齐、进度告知这几段串起来。
环节原来的处理方式设计后的处理方式
理赔补资料通知人工逐个外呼，难以覆盖外呼触达并记录接听情况
通话留痕录音留存但检索困难录音转写并与工单关联
节假日咨询转接手机，依赖个人响应按规则转接并保留记录
事故服务协同群内人工跟单群助手、语音机器人、质检组合承接
上表为改造目标与路径设计，不代表已经实现的效果。具体口径以项目实际配置与客户侧业务规则为准，本节不提供量化成效声明。

八、把五步串起来：落地检查表与常见返工点

回看这套方法，它其实只有一条主线：先按四个信号给条款咨询定级，再让每一级配一个可配置的落点。知识底座负责"找得到、可引用"，知识图谱负责"跨文档拼得齐"，锁口径负责"说得准"，业务接入负责"办得完"，人工复核负责"兜得住、留得下"。
把五步合成一张检查表，每行对应一步，勾完就基本覆盖了落地的主要工作量：
步骤落地动作客户侧要提前准备验收标准常见返工点
分级按四信号定级，明确各级边界与业务、合规共同确认边界四级边界书面确认边界订得太细，后续难维护
知识底座导原始文档、切片检索、建生命周期与权限版本归属、术语口径表、更新责任人答案可回指文档与版本先拆 FAQ，原文不可回溯
知识图谱设计实体与关系，覆盖跨文档问题业务方参与实体关系设计复杂问题能一次召回相关条款全场景套图谱，成本失控
锁口径区分可生成与需锁定的表述确定哪些内容必须固定关键表述无自由改写锁得过死，退化成规则应答
业务接入校验身份、调系统取数、建单工单接口权限、办理前置条件、技能组查询不落人工、上下文不丢转人工后要求客户复述
人工复核建议与草稿、复核节点、留痕复核触发条件与处理人原始数据与推理路径可追溯节点无触发条件，形同虚设
在外围还有几项扩展能力可以一并考虑：质检与 VOC 回流用于发现问题并反哺知识；私有化部署与数据不出域用于满足数据合规要求；电话与在线共享同一套知识来源，避免两个渠道说法不一致。这几项不单独成体系，但它们决定了这套方法能不能长期运转。
责任边界最后再说一次：AI 只做引导与服务动作，判断类事项全部转人。落到具体业务上，就是 AI 可以承担流程咨询、导诊指引、预约引导、资料准备、服务导航、理赔材料说明、工单协同和坐席辅助。
涉及合规、风控、授信、理赔、交易和资金等专业判断时，需要人工审核、流程留痕和系统权限控制。监管对这类应用的要求是完善人机协同的业务管理流程、科学设定功能边界与系统和数据权限，明确人员岗位责任，确保业务全流程管理责任清晰、可落实、可追溯——这套检查表，就是把这句话拆成了六行可以勾选的条目。
合力亿捷的保险 AI 客服方案，是在这套分级与复核框架下展开的。它以悦问知识库作为可引用、可授权、可运营的知识底座，用知识图谱把条款之间的关系串起来，用关键回答可控把政策、规则与金额的表述锁住。
再由在线客服 Agent、电话 Agent 与坐席辅助 Agent 在同一套知识来源上承接接待、办理与复核。对正在评估保险智能客服的团队来说，值得优先问清的是"你的分级边界画在哪、复核节点怎么留痕"，而"知识图谱支不支持"这类功能清单可以往后放——前两个问题的答案，才决定 AI 能不能真正进到条款咨询这类场景里。

九、常见问题（FAQ）

Q1：条款更新后，要不要重新验证所有流程？
分两层看。知识层按生命周期与到期日期做替换和重试，过期版本会被识别出来，不必人工逐个排查；流程层按变更影响面圈定范围，只回归受影响的那几条链路，不必全量重跑。判断影响面的依据，来自命中分析和知识缺口的运营数据。
Q2：客户资料不全时，AI 能不能先受理？
不能。AI 只能提示客户还缺哪些材料、并把这个状态记录下来，受理条件本身由客户侧的业务规则决定。让 AI 在资料不全时"先收下"，等于替业务做了判断，这是典型越界。
Q3：哪些问题一定会转人工？
按风险、场景、时段和对话状态综合定义，而不是单看关键词。有一条底线是明确的：涉及合规、风控、理赔、责任认定、资金等的判断类问题，一律转人。保险场景里，"能不能赔""赔多少""哪条条款适用"这三类问题都属于此列。
Q4：上了知识图谱，是不是就不会答错了？
不是。图谱解决的是"找得准、能跨文档把相关条款拼齐"，答案口径的正确性仍取决于知识质量、权限设置、检索结果与生成约束。关键表述还要靠锁口径配置来保证。图谱提升的是召回质量，不是答案的合规性。
Q5：客户信息能不能直接放进知识库？
要先做数据分类分级。监管明确，姓名、身份证号、手机号、银行卡号等个人信息和隐私数据不得用于生成式人工智能模型训练和优化。知识库能放什么、不能放什么，建议在建设前就和法务、合规一起定下来。