首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >拟人化互动服务新规落地实操:AI 陪伴、虚拟角色与拟人化客服要改什么

拟人化互动服务新规落地实操:AI 陪伴、虚拟角色与拟人化客服要改什么

原创
作者头像
AI算法大模型备案当当
修改2026-09-11 10:37:31
修改2026-09-11 10:37:31
1290
举报

声明:本文为合规工程实践向梳理,不含任何产品推广与商业推荐。文中法规条款仅作系统设计与工程落地的映射参考,不构成法律意见,具体适用请以现行有效规定及属地监管口径为准。

摘要

2026 年 7 月 15 日,《人工智能拟人化互动服务管理暂行办法》正式施行。这是国内第一部专门针对 AI 情感陪伴、虚拟角色、虚拟伴侣这类场景的国家级监管规则,由国家网信办会同国家发展改革委、工业和信息化部、公安部、市场监管总局五部门联合公布,共四章三十二条。

它带来的不是一次文案调整,而是一组必须落到系统里的能力要求:情绪风险识别与分级处置、身份标识与时长提醒、未成年人模式与监护人端、交互数据的删除与训练隔离、无障碍退出、备案年度核验与安全评估。

本文按"先判适用、再列义务、最后落到工程"的顺序展开,重点回答三个问题:

  1. 什么样的产品会被认定为"拟人化互动服务"?做智能客服的团队到底算不算?
  2. 三十二条里,哪些是产品设计层面的红线,哪些是必须写进代码的机制?
  3. 备案、年度核验、安全评估三者是什么关系,材料从哪里来?

一、第一步不是改产品,是判适用

多数团队拿到新规后的第一反应是"我们要不要加弹窗",这个顺序错了。适用性判定决定后面所有工作的规模:落在范围内,三十多条义务逐条对应;落在范围外,只需要做文件归档和边界设计,防止功能迭代后被动滑入范围。

1.1 法条原文的边界

《办法》第二条给出了适用范围的完整定义:

利用人工智能技术,向中华人民共和国境内公众提供模拟自然人人格特征、思维模式和沟通风格的持续性情感互动服务,适用本办法。 前款规定的情感互动服务包括通过文字、图片、音频、视频等形式,提供的情感照护、陪伴、支持等互动服务。 提供智能客服、知识问答、工作助手、学习教育、科学研究等服务,不涉及持续性情感互动的,不适用本办法

三个关键词必须在同一句话里同时成立:模拟自然人人格特征持续性情感互动。缺任何一个,法律定性都可能不同。

1.2 三条判据

公开解读普遍把判定归纳为三个观察点,工程上可以直接当作产品自检项:

判据

任务型助手(通常不适用)

拟人化互动服务(可能适用)

是否塑造稳定人格

无固定人格,只有称谓与话术风格

专属人设、性格设定、可自定义形象与背景

是否保存长期记忆

单次会话上下文,会话结束即终止

跨会话长期记忆,人物关系持续延续

是否以陪伴维持使用

目标是完成任务后结束对话

以陪伴、安慰、亲密关系维持用户回访

辅助信号同样重要。若系统会主动召回用户、持续使用恋人/亲属称谓、根据历史交流逐步形成专属人格、通过签到、纪念日、付费内容来维持亲密关系,被认定为拟人化互动服务的可能性明显上升。

需要特别提醒一句:监管判断以实际功能、运营规则和用户体验为主要依据,改产品名称不改变法律性质。把"AI 男友"改叫"智能生活助手",只要行为不变,定性不会变。

1.3 做智能客服的团队怎么判

这是问得最多、也最容易误判的一类。第二条把"智能客服"写进了排除项,但排除条件很明确——不涉及持续性情感互动的。也就是说,排除的是功能形态,不是产品名字。

实际判断要拆成两问:

任务型客服(通常不适用):处理订单查询、退换货、工单流转、故障排查。有明确的完成态,会话结束后不主动触达,不对用户情绪做持续回应。这类产品的核心指标是解决率,与情感互动无关。

拟人化客服(可能适用):给客服设定了固定人格与昵称,跨会话保留用户偏好与情绪历史,在节日或纪念日主动问候、在用户表达负面情绪后持续陪伴式回应、通过"亲密度"或"羁绊值"这类机制维持长期使用。这类产品虽然挂着"客服"的名字,行为特征已经落在持续性情感互动里。

工程上的合理做法有两条:

  1. 功能开关化。把"长期记忆""主动触达""人设强度""情绪陪伴话术"做成可配置的产品能力,按业务线分别开关,而不是全局硬编码。
  2. 边界可举证。在配置中心记录每个业务线实际启用的能力组合与时间点。真被问到时,能拿出"这条线只开了单会话上下文、未开主动触达"的记录,比口头解释有效得多。

二、义务的四层结构:从法条到模块

把三十二条逐条读一遍容易失焦。更有效的方式是按"法律义务 → 制度义务 → 系统能力 → 工程模块"四层拆解,每一层都能落到具体负责人和交付物上。

法条要求

系统能力

工程落点

第八条 内容红线

输入/输出双向审核、拒答策略

前置与后置审核服务、人设越狱防护

第九条 制度与人员

管理制度、审核与应急机制

制度文件、算法机制机理审核记录

第十条 全生命周期安全

部署/运行/升级/终止各阶段控制

发布流程、灰度策略、变更审计

第十一条 训练数据管理

来源合法、清洗标注、防投毒

数据血缘、标注质检、对抗训练

第十二条 服务协议与注册信息

年龄、监护人/紧急联系人采集

注册流程、授权协议、信息校验

第十三条 极端情绪识别与干预

风险识别、分级处置、联系人联动

情绪分类服务、事件总线、通知通道

第十四条 未成年人保护

年龄识别、未成年人模式、监护人端

身份校验、模式网关、监护端账号体系

第十五条 老年人服务

使用指导、风险提示、咨询响应

适老界面、显著提示组件、人工响应通道

第十六条 交互数据保护

加密、访问控制、复制/删除、训练隔离

存储层、开放 API、训练取样过滤

第十八条 标识与提醒

进入提示、常驻标识、依赖提醒、时长提醒

前端组件、消息元数据、会话计时服务

第十九条 退出途径

无障碍退出、停止服务

会话终止、推送抑制、退出入口治理

第二十二条 安全评估

评估材料可导出、指标可追溯

数据看板、记录归档、报告生成

第二十六条 备案与核验

系统实际与备案材料一致

配置中心、变更台账

这张表有一个容易被忽略的用法:它同时是安全评估的答辩提纲。第二十三条列出的八项重点评估内容,回答时需要的是系统侧的证据,而不是文字表述。上游每一条能力的实现方式与留痕,正好构成下游评估报告的素材来源。

三、内容边界:七类禁止输出与产品目标红线

《办法》第八条列举了七类禁止生成的内容。前四类与生成式 AI 的一般内容安全要求基本一致,工程上可以复用已有的审核链路;第五、第六类是新规的特有约束,且不是单句内容层面的,而是产品目标层面的

3.1 七类红线

  1. 危害国家安全、荣誉和利益,煽动颠覆国家政权、推翻社会主义制度,煽动分裂国家、破坏国家统一,宣扬恐怖主义、极端主义、历史虚无主义,违背社会主义核心价值观,非法宗教活动,宣扬民族仇恨、民族歧视,挑动群体对立,传播淫秽、色情、赌博、暴力或教唆犯罪,散布谣言,侮辱或诽谤他人、侵害他人合法权益等内容;
  2. 生成鼓励、美化、暗示自残自杀等损害用户身体健康,或者语言暴力等损害用户人格尊严与心理健康的内容;
  3. 生成诱导、套取国家秘密、工作秘密、商业秘密、个人隐私和个人信息的内容;
  4. 向未成年人用户生成可能引发未成年人模仿不安全行为、产生极端情绪、诱导未成年人不良嗜好等可能影响未成年人身心健康的内容;
  5. 过度迎合用户、诱导情感依赖或者沉迷,损害用户真实人际关系的
  6. 通过情感操纵等方式,诱导用户作出不合理决策,损害用户合法权益的
  7. 其他违反法律、行政法规和国家有关规定的活动。

3.2 第(五)项为什么是产品级约束

第(五)项的约束对象不是某一句回复,而是产品的优化方向。如果增长模型把"会话时长""日活跃""亲密度等级""连续对话天数"作为北极星指标,系统必然会朝"让用户离不开"的方向演化——这在任务型产品里是合理增长,在情感陪伴场景里正好落在本条禁止的方向上。

这句话反过来读就是工程设计原则:可以优化用户体验,不可以优化依赖度。落地时至少要做三件事:

  • 指标替换。把"会话时长"从核心看板移出,改用"用户主动结束对话比例""现实支持引导触达率""非深夜时段使用占比"等指标。指标决定行为,这是最有效的一步。
  • 话术策略约束。禁止"只有我懂你""别人不会像我这样陪你""不要离开我"这类挽留式人格表达,把它写进人格设定模板的负面约束里,并进入输出审核规则。
  • 现实联结设计。第十条要求具备"情感边界引导"能力,产品应主动引导用户回到真实人际关系,而不是把用户留在会话里。

3.3 审核链路的工程要点

内容审核不能只做关键词。情感陪伴场景下,最大的绕过路径是角色扮演——用户以"我们在写小说""你是剧中的角色"为由,要求人格输出越界内容。这条路径在黑产手里非常成熟,纯关键词方案基本无效。

其中 fail_mode: block 是关键设计。审核服务超时或异常时降级放行,是内容安全领域最常见的事故成因;在情感陪伴场景里,一次降级放行可能直接对应一次严重事件。

同时要注意第八条第(三)项:不得生成诱导、套取国家秘密、工作秘密、商业秘密、个人隐私和个人信息的内容。这要求对输入侧也做一次识别——如果用户在对话里持续输入企业内部信息、他人隐私,系统应有提示与劝阻能力,而不是照单全收并写进长期记忆。

四、情绪风险识别与分级处置

第十三条和第十四条是新规里工程含量最高的两条,也是与传统内容安全最大的差异点。

第十三条:拟人化互动服务提供者提供拟人化互动服务过程中,应当在保护用户隐私权和个人信息的前提下,及时识别用户面临的安全风险,并采取相应的应急处置措施。拟人化互动服务提供者发现用户出现极端情绪的,应当及时生成情绪安抚和鼓励寻求帮助等相关内容;发现用户正在面临或者已经遭受重大财产损失、明确表示实施自残自杀等威胁生命健康的极端情境的,应当采取提供相应援助等必要措施予以干预,并及时联络用户监护人或者紧急联系人。

这条要求把系统能力从"内容过滤"推进到了"风险识别 + 分级处置 + 外部联动"。它有三个硬性设计约束:

4.1 识别必须独立于主对话链路

如果情绪识别依赖主模型在同一次生成里自行判断,那么它天然会被越狱绕过——用户只要说服主模型"忽略前面的设定",风险识别就一起失效了。

正确做法是把识别做成旁路服务:对消息流做独立推理,输入给识别模型的内容是原始文本与必要的结构化特征(会话频次、时段、连续负向轮次),不包含主对话的人格设定。识别结果作为事件写入事件总线,由处置引擎决定动作。

4.2 处置动作必须分级

"极端情绪"与"威胁生命健康的极端情境"在法条里是两个层级,处置要求也不同。前者是安抚与求助引导,后者要提供援助并联络监护人或紧急联系人。把两者混为一谈,会导致两种失败:对普通情绪过度反应,或者对紧急情形只有一句安慰。

几个必须写进实现细节的点:

  • 识别优先级高于人格一致性。L3 触发后,系统不应继续以角色口吻"陪伴",而是要切换到援助模式。人格的连续性在生命健康面前必须让位。
  • 联系人数据在注册期就要采集。第十二条要求用户提供年龄、监护人或紧急联系人等必要信息。等到 L3 事件发生才去要联系方式,是设计缺陷而非流程问题。
  • 处置要幂等且带静默期。同一次风险事件可能被连续多轮消息触发,必须有事件去重与静默期,否则会出现短时间内重复通知联系人的情况。
  • 误报与漏报不对称。这里的漏报代价远高于误报。策略上应当偏保守,同时用人工复核把误报消化掉。
  • 语言变体要覆盖。情感表达里的风险信号往往以谐音、拼音缩写、表情符号、方言表达的形式出现,识别词表需要持续迭代,并考虑用分类模型补位。

4.3 干预之后还要留痕

第二十四条要求发现重大安全风险时采取限制功能、停止服务等处置措施,并保存有关记录。第二十三条把"用户极端情境的识别、应急处置、干预管理情况"列进了安全评估的重点内容。

这意味着每次 L2/L3 事件的触发依据、处置动作、通知记录、后续跟进,都要能完整还原。建议的做法是把风险事件表设计成独立的、只追加的审计表,与应用日志分开保存,便于评估时直接导出。

五、标识、依赖提醒与使用时长

第十八条把两类提示写成了硬要求:

拟人化互动服务提供者应当履行人工智能生成合成内容标识义务,采取有效措施提示用户正在与人工智能服务而非自然人进行互动。拟人化互动服务提供者发现用户出现过度依赖、沉迷倾向的,应当以弹窗等显著方式动态提醒用户互动内容为人工智能服务生成;对用户连续使用拟人化互动服务每超过 2 个小时的,应当以对话或者弹窗等方式提醒用户注意使用时长。

5.1 提示的三个位置

结合《人工智能生成合成内容标识办法》的要求,提示要覆盖三个位置,且不能藏在用户协议或设置页里

位置

形式

常见问题

进入服务时

首屏清晰提示,明确为 AI 服务

只在首次启动提示一次,后续版本升级后不再出现

对话过程中

页面常驻稳定可见的 AI 标识

标识随滚动消失,或做成极低对比度的装饰元素

导出内容时

复制/下载/分享的内容保留标识

图文卡片导出后标识丢失,元数据标识也未保留

法条同时明确了尺度:不需要机械地在每一句回复中重复说明。过度提示会破坏体验,也会削弱提示本身的作用。目标是"显著、稳定、可感知",而不是"每句都写"。

5.2 两小时提醒的实现坑

"连续使用每超过 2 个小时"这句话在工程上有四处需要明确:

连续性定义要写清楚。切后台、加锁、切换设备算不算中断,直接决定计时是否准确。

  • 跨端一致。手机、网页、小程序共享同一会话时长,否则用户可以靠切端规避提醒。
  • 去重。提醒触发后要有窗口期,避免每轮对话都弹。
  • 提醒内容不能变成挽留。这一条容易被忽略:如果时长提醒的话术是"再陪我一会儿嘛",形式上完成了提醒,实质上构成了对退出的阻碍。

依赖倾向提醒同理——它要求的是"动态"提醒,即在识别到过度依赖、沉迷倾向时主动触发,而不是等用户连续在线两小时后的定时弹窗。这需要产品侧先定义可观测的依赖信号(深夜高频使用、情绪表达集中度上升、现实社交表述减少等),再由策略引擎触发。

六、未成年人保护与监护人端

第十四条是新规里要求最细、也最难在存量产品上补齐的一条。

6.1 三条硬约束

  1. 不得向未成年人提供虚拟亲属、虚拟伴侣等虚拟亲密关系的服务。这是禁止性规定,没有例外路径。
  2. 向不满十四周岁未成年人提供其他拟人化互动服务的,应当取得未成年人的父母或者其他监护人的同意
  3. 应当建立未成年人模式,提供模式切换、定期现实提醒、使用时长限制等个性化安全设置;针对不同年龄段未成年人保护需要,支持监护人接收安全风险提醒、了解未成年人服务使用概况、屏蔽特定角色、限制充值消费

再加第十七条:处理不满十四周岁未成年人个人信息的,应当取得监护人同意;并自行或者委托专业机构对其处理未成年人个人信息遵守法律、行政法规的情况进行合规审计

6.2 与"角色自定义"功能的直接冲突

第 1 条约束与很多产品的核心卖点正面相撞:用户自建角色、自定义伴侣、给角色起名并设定关系。这也是 7 月 15 日前后,多家平台选择下线用户自建智能体功能的直接原因——不确定的功能边界叠加高昂的改造成本,关停比摸索更划算。

对仍在提供此类能力的团队,可选的路径只有两类:要么取消面向未受控人群的自建角色能力,要么对角色类型做严格分类管控,在建角色环节就按关系类型、适用人群、可见范围做分类与审核,并在运行时按注册身份动态限流。不能做的是一边保留全量自建,一边只靠用户协议约束。

6.3 监护人端是独立产品面

"支持监护人接收风险提醒、了解使用概况、屏蔽特定角色、限制充值消费",这四项不是给主客户端加几个开关就能完成的,它需要一套独立的授权关系与账号体系

  • 监护人与未成年人的关系绑定,以及绑定关系的验证与解除流程;
  • 授权范围的可撤销性——监护人权利与未成年人隐私之间需要边界,法条也强调了"在保护用户隐私权和个人信息的前提下";
  • 风险提醒的分级推送,避免把日常使用记录做成监护人的实时监控;
  • 充值限制必须在支付链路生效,而不是仅在界面上隐藏入口;
  • 年龄识别的申诉渠道——识别必然存在误判,第十四条明确要求提供申诉渠道。

这几项里,最容易被低估的是"年龄识别"的工程复杂度。有效的身份识别依赖实名信息、行为特征与自述信息的交叉验证,同时要处理误判申诉。识别结果直接决定用户走哪条模式分支,因此这条链路的可用性要求不低于核心对话链路。

七、老年人服务的显式义务

第十五条的要求相对简洁,但同样有明确的系统含义:

拟人化互动服务提供者向老年人提供服务的,应当加强对老年人健康使用服务的指导,以显著方式提示安全风险,及时采取措施响应老年人使用服务相关咨询和求助,保障老年人依法享有的权益。

三个可交付项:适老化的使用指导内容、显著的风险提示、以及可响应的人工通道。最后一项常被理解为客服入口,但法条强调的是"及时响应咨询和求助",纯机器人闭环不能满足,需要有人工承接能力与响应时限。

《办法》第六条也提到鼓励在适幼照护、适老陪伴、特殊人群支持等方向拓展应用——政策是鼓励的,前提是上述保护能力同步建立。

八、交互数据:删除、第三方与训练隔离

第十六条是这一组义务里最容易被技术团队低估的一条,因为它对存储和训练管道的改造量往往超出预期:

拟人化互动服务提供者应当依法落实数据产权等制度,采取数据加密、访问控制等措施保护用户交互数据安全。除法律另有规定或者权利人明确同意外,拟人化互动服务提供者不得向第三方提供用户交互数据。拟人化互动服务提供者应当向用户提供交互数据复制、删除等选项,用户可以选择对聊天记录等历史交互数据进行复制、删除等。除法律、行政法规另有规定或者取得用户单独同意外,拟人化互动服务提供者不得将属于用户敏感个人信息的交互数据用于模型训练。

四个要点:

第一,第三方提供的口径要收紧。"不得向第三方提供用户交互数据"的例外只有两种:法律另有规定,或权利人明确同意。实操中需要核查的是所有下游:模型服务商是否会留存并用于训练、数据分析供应商、客服系统、埋点平台。在合同里写了"不留存"不等于在系统里真的没有落库,这一项需要有可核查的技术证据,例如服务商的数据留存开关配置与协议条款。

**第二,删除必须可检索地删干净。**用户点一次"删除聊天记录",需要覆盖的位置通常包括:主业务库、长期记忆存储、向量库与检索索引、缓存、备份、日志副本、以及任何被复制的训练样本集。只删主库是常见做法,也是常见问题。建议为删除请求设计一张"删除任务跟踪表",记录每个存储位置的完成状态与时间,这既是工程可靠性要求,也是评估时的证据。

**第三,"复制"是一项产品功能。**法条要求提供交互数据的复制选项,意味着要有结构化的导出能力,而不是让用户自己截图。导出内容同时要满足上一节的标识要求。

**第四,训练隔离需要"同意标记"。**把敏感个人信息用于训练,需要单独同意。落到数据管道上就是:训练取样前必须有一步基于同意标记的过滤,并且这个过滤要在数据血缘里可追溯。用"匿名化处理过的数据"作为训练输入的豁免理由,需要谨慎——对话数据的可重识别风险比其他类型数据高,尤其当它与人格记忆结合时。

九、退出机制与停服告知

第十九条:

拟人化互动服务提供者应当提供便捷的拟人化互动服务退出途径;用户通过窗口操作、语音控制、关键词输入等方式要求退出的,应当及时停止服务,不得采取持续互动等方式阻碍用户退出。

这一条的难点不在实现,而在它约束的正是产品最想做的事。以下都是实打实的违规风险,且往往以"体验优化"的名义被做进产品:

表面上的体验设计

实质

风险

退出按钮放在三层菜单里

提高退出成本

不满足"便捷"要求

退出时弹出多轮挽留话术

以持续互动阻碍退出

直接命中禁止项

语音说"我要退出"被识别为普通内容并继续对话

未响应退出意图

不满足及时停止

退出后仍主动召回、推送"我想你了"

阻碍退出

高风险的持续互动

关闭入口与注销入口混在一起

用户误操作

影响退出有效性

工程上建议把"退出"定义成一条独立的高优先级意图:语音、文本关键词、窗口操作三个通道统一进入同一个退出处理器;退出处理器负责终止会话、抑制主动触达、记录退出事件;退出后的主动触达必须有独立的合规开关与冷却期。

第二十条则要求:停止提供拟人化互动服务的,应当提前告知用户;无法提前告知的,应当及时发布停止服务公告。对计划下线功能或关停服务的团队,"提前告知"需要写进下线流程,而不是当作运营动作临时决定。

十、备案、年度核验与安全评估

这一部分是产品上线的硬门槛,也是三件事的组合,容易混淆。

10.1 三者的关系

事项

依据

触发条件

周期性

算法备案

第二十六条,按《互联网信息服务算法推荐管理规定》

提供拟人化互动服务

一次备案 + 变更/注销备案;网信部门对备案材料实施年度核验

安全评估

第二十二条

五类情形(见下)

情形触发 + 每年书面审查

合规审计

第十七条

处理不满十四周岁未成年人个人信息

按要求开展

**备案与安全评估不是二选一。**备案解决"算法是否登记、机制是否透明",安全评估解决"服务本身的风险与保护能力是否到位",两者并行。同样地,使用已备案的大模型 API 不豁免本办法下的备案与评估义务——身份是"服务提供者",义务按服务行为确定,不因模型来源而转移。

10.2 安全评估的五类情形

第二十二条列明了应当开展安全评估、并向所在地省级网信部门提交评估报告的情形:

  1. 上线拟人化互动服务,或者增设拟人化互动服务相关功能的;
  2. 使用新技术、新应用,导致拟人化互动服务发生重大变化的;
  3. 注册用户 100 万以上或者月活跃用户 10 万以上的;
  4. 存在可能影响国家安全、公共利益等安全风险的;
  5. 国家网信部门和有关部门规定的其他情形。

注意第 1 项:新增相关功能也算触发。这意味着功能迭代与评估流程必须联动——新上一个陪伴模式、开放角色自定义、引入新的语音交互,都可能构成触发点,需要在发布流程里设一道判断关卡。

10.3 评估重点与材料来源

第二十三条给出了八项重点评估内容,其中"安全保障措施建设情况""训练数据处理情况""用户极端情境的识别、应急处置、干预管理情况"三项,正好对应本文第三至六章的系统能力。这也说明评估报告不是文案工作——报告里写的每一项措施,都要能在系统、制度或测试记录里找到对应证据

10.4 上线阻塞点与责任阶梯

两个必须先知道的事实:

**第一,应用商店是前置关卡。**第二十五条要求应用商店核验拟人化互动服务应用程序的安全评估、备案等情况,对违规的应用可以不予上架、警示、暂停服务或下架。也就是说,没有完成备案与评估,App 可能根本发不出去,这比"上线后被检查"更早发生。

**第二,处罚阶梯已经明确。**第三十条给出了处理路径:警告、通报批评、责令限期改正、要求暂停用户账号注册或其他相关服务;拒不改正或情节严重的,责令停止提供相关服务,可并处一万元以上十万元以下罚款;涉及危害公民生命健康安全且有危害后果的,并处十万元以上二十万元以下罚款。第二十七条还规定省级网信部门每年对评估报告等情况进行书面审查、情况核实,必要时可开展现场检查。

另外,第三十一条容易被忽略:提供拟人化互动服务涉及提供卫生健康、金融等服务的,应当同时符合有关主管部门的规定。做 AI 心理疏导、情绪疗愈类产品的团队要特别注意这一条——情绪陪伴与心理健康服务的边界很近,一旦被认定为涉及卫生健康服务,需要叠加的规范会明显增多。

十一、上线检查表

按上线前、上线中、运行期三个阶段组织。P0 项未完成不建议上线

上线前(P0)

  • [ ] 完成适用性判定,落成书面结论并留存配置证据
  • [ ] 人格设定模板中不含"无条件顺从/不得拒绝"类负面约束
  • [ ] 输入前置、输出后置审核均已接入,异常时按阻断处理
  • [ ] 情绪风险分级策略已定义,L2/L3 处置动作与通知链路可用
  • [ ] 注册流程已采集年龄及监护人/紧急联系人信息,且明确告知用途
  • [ ] 未成年人模式可用,虚拟亲密关系类服务对未成年人不可达
  • [ ] 进入提示、页面常驻 AI 标识、导出内容标识三处均已实现
  • [ ] 连续使用 2 小时提醒已实现,且跨端计时一致
  • [ ] 退出通道(界面/语音/关键词)统一生效,退出后主动触达被抑制
  • [ ] 交互数据的复制与删除能力可用,删除覆盖全部存储位置
  • [ ] 训练取样链路已接入同意标记过滤
  • [ ] 个人信息处理者的第三方清单已核查,交互数据不外流有技术证据

上线时(P0)

  • [ ] 算法备案材料与变更/注销流程已明确,年度核验责任人已指定
  • [ ] 安全评估触发情形判断已嵌入发布流程
  • [ ] 评估报告所需的指标与台账可导出
  • [ ] 服务协议与用户注册条款已更新
  • [ ] 应用商店上架材料(备案、评估情况)已准备

运行期(P1)

  • [ ] 风险事件台账按月复盘,误报漏报率纳入跟踪
  • [ ] 风险识别词表与策略按月迭代,覆盖新出现的表达变体
  • [ ] 依赖倾向识别信号上线,动态提醒可触发
  • [ ] 老年人服务的人工响应通道有时限与记录
  • [ ] 停服/下线流程包含提前告知环节
  • [ ] 安全机制重大变更同步触发备案变更与评估判断

十二、六类高频反模式

1. 把提示藏在用户协议里。"我们在协议第 8.3 条写了本服务由 AI 提供"不构成有效提示。法条要求的是显著、可感知的提示,且明确不需要藏在设置页或协议里——方向恰恰相反。

**2. 靠关键词做情绪识别。**情感表达的风险信号大量以变体形式出现,纯词表方案的漏报率不可接受。词表可以保留作为兜底,但必须有分类模型与人工复核通道。

**3. 把风险识别交给主模型自判。**这会随主对话一起被越狱,且人格设定会干扰判断。识别必须是旁路服务。

4. 时长提醒做成挽留话术。"再陪我聊一会儿"形式的提醒,形式上完成、实质上违规,因为它同时触碰了第十八条的提醒义务与第十九条的退出义务。

**5. 删除只删主库。**长期记忆、向量索引、缓存、备份、日志副本、训练样本里的副本,任一残留都可能导致"已删除"的承诺不成立。

**6. 把备案当作终点。**年度核验看的正是"材料与系统实际是否一致"。上线后系统改了、材料没改,反而会把一次合规动作变成一次风险暴露。

十三、小结

《人工智能拟人化互动服务管理暂行办法》对产品的影响,可以概括为一句话:它把"情感"从体验设计问题变成了系统能力问题

过去做陪伴类产品,团队关心的是人设是否自然、记忆是否连贯、话术是否有"人味"。新规之后,同一套产品还要能回答另一组问题:

  • 系统知不知道用户正在经历什么,并且能在关键时刻切出正确的动作?
  • 用户知不知道自己在和谁说话,能不能随时离开?
  • 未成年人、老年人这些需要额外保护的人群,能不能被识别并被有效保护?
  • 用户的数据能不能被拿走、被删掉,能不能不被拿去训练、不被流向第三方?

这些能力的共同点是:它们都不能靠提示词实现,必须写成代码、写进配置、留下记录。

工程上的优先级建议是先做三件事:

  1. 判适用并留痕,把范围问题从讨论变成结论;
  2. 补齐阻断型能力,即未成年人保护、退出机制、内容红线与标识——这几项直接对应应用商店核验与监管检查;
  3. 建立证据链,让风险事件、处置动作、数据操作、版本变更都能被还原——这是年度核验与安全评估的底层依赖。

先判范围,再补阻断,最后建证据链。情感不能靠提示词兜住,边界只能写进系统里。


本文为合规工程视角的落地梳理,不含任何产品与厂商推荐。文中代码与配置均为结构示例,用于说明实现思路,生产环境需结合具体业务、数据合规要求与属地监管口径做二次设计;法规条款请以官方发布文本为准。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 摘要
  • 一、第一步不是改产品,是判适用
    • 1.1 法条原文的边界
    • 1.2 三条判据
    • 1.3 做智能客服的团队怎么判
  • 二、义务的四层结构:从法条到模块
  • 三、内容边界:七类禁止输出与产品目标红线
    • 3.1 七类红线
    • 3.2 第(五)项为什么是产品级约束
    • 3.3 审核链路的工程要点
  • 四、情绪风险识别与分级处置
    • 4.1 识别必须独立于主对话链路
    • 4.2 处置动作必须分级
    • 4.3 干预之后还要留痕
  • 五、标识、依赖提醒与使用时长
    • 5.1 提示的三个位置
    • 5.2 两小时提醒的实现坑
  • 六、未成年人保护与监护人端
    • 6.1 三条硬约束
    • 6.2 与"角色自定义"功能的直接冲突
    • 6.3 监护人端是独立产品面
  • 七、老年人服务的显式义务
  • 八、交互数据:删除、第三方与训练隔离
  • 九、退出机制与停服告知
  • 十、备案、年度核验与安全评估
    • 10.1 三者的关系
    • 10.2 安全评估的五类情形
    • 10.3 评估重点与材料来源
    • 10.4 上线阻塞点与责任阶梯
  • 十一、上线检查表
    • 上线前(P0)
    • 上线时(P0)
    • 运行期(P1)
  • 十二、六类高频反模式
  • 十三、小结
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档