AI 客服新规豁免判定:我把第二条第 3 款做成了可执行的判断逻辑

发布时间:2026/10/15 9:05:57
AI 客服新规豁免判定:我把第二条第 3 款做成了可执行的判断逻辑
AI 客服新规豁免判定我把第二条第 3 款做成了可执行的判断逻辑一、先说结论《人工智能拟人化互动服务管理暂行办法》网信办等五部门令第 21 号2026-04-10 公布2026-07-15 施行第二条第 3 款明文排除智能客服、知识问答、工作助手、学习教育、科学研究——前提是不涉及持续性情感互动。对绝大多数接了大模型的工单/客服系统来说这意味着不需要按本办法做第 22 条的安全评估、不需要按第 26 条做算法备案。但这条豁免是跟着产品形态走的不是跟着公司走的。本文给一套可以直接写进代码的判定逻辑。二、条款拆解三个判定维度第二条把适用范围拆成三个必要条件缺一不成立维度条款表述工程上对应什么对象模拟自然人人格特征、思维模式和沟通风格系统提示词里有没有「人格设定」行为持续性的情感互动服务有没有跨会话记忆 情绪应答形式文字/图片/音频/视频的情感照护、陪伴、支持产品形态是不是陪伴类排除条款只针对「智能客服/知识问答/工作助手/学习教育/科研」「不涉及持续性情感互动」。三、可执行的判定逻辑伪代码def is_anthropomorphic_service(session) - bool: True 落入《拟人化互动服务办法》管辖 signals [ session.prompt_has_persona, # 提示词含人格/人设设定 session.has_cross_session_memory, # 跨会话记忆上次你说过 session.responds_to_emotion, # 用户未提情绪却主动安慰 session.goal_is_engagement, # 目标函数是停留时长而非解决率 ] # 排除条款智能客服 不涉及持续性情感互动 → 不适用 if session.kind in (customer_service, qa, work_assistant): if not any(signals): return False # 豁免 return any(signals[:3]) # 命中任一 → 落入管辖判据要点豁免不是看kind是看kind和signals的组合。kindcustomer_service但goal_is_engagementTrue照样出线。四、一个容易漏的点第 16 条与豁免无关办法第十六条要求交互数据加密与访问控制、非经用户单独同意不得将敏感个人信息交互数据用于模型训练、除法定情形外不得向第三方提供交互数据。这一条的逻辑基础是《个人信息保护法》不是本办法的适用范围。即使你的客服在豁免侧这些义务照样存在。五、另一部真正管 AI 客服的GB/T 47746—2026《顾客联络服务 人工与智能客户服务协同要求》2026-09-01 实施。推荐性国标但客户投诉、平台规则都会拿它当尺子。我把它拆成 61 项48「应」4「宜」9「可」含 5 项一票项工程上必做的是前四条转人工入口醒目禁止层层隐藏复杂纠纷资金争议人身财产安全风险用户明确要求 →及时转接切换不得要求消费者重复陈述企业为 AI 回复负责不得以「算法自动生成」推责六、给技术人的落点如果你在写客服系统建议加一个escalation_gate中间件在返回前拦一次MUST_ESCALATE (退款, 赔偿, 投诉, 人身安全, 找人工, 转人工) def escalation_gate(reply: str, user_msg: str, ctx) - dict: if any(k in user_msg for k in MUST_ESCALATE) or ctx.risk_level high: return {action: escalate, reason: must_transfer, reply: None} return {action: reply, reply: reply}这样做的收益把「该转没转」从人工判定的模糊问题变成一次可测的拦截率——顺手也就满足了国标第 2 条。七、结论客服系统大概率不适用《拟人化互动服务办法》但要能自证为什么——把上面的判定逻辑落成代码或清单。真正要补的是GB/T 47746—2026 的 61 项尤其转人工门控。第 16 条的数据义务与豁免无关别漏。我们专注面向 200 人以下小微企业的企业知识库与 AI 客服落地。