7月15日《人工智能拟人化互动服务管理暂行办法》正式施行后，未成年人防护成为所有UGC拟人Agent必须直面的硬性合规要求。《办法》第十四条明确禁止向未成年人提供虚拟恋人、专属陪伴类服务，并要求对未成年人交互执行时长限制、深夜切断、监护人授权等一系列强制性措施。

然而，在近期对多家情感AI团队的技术排查中，我发现绝大多数产品的未成年人防护，仍然停留在“前端弹窗+年龄自选”的补丁阶段。这套方案在监管审查面前，几乎形同虚设。

今天这篇文章，我将基于前几篇拆解过的风控中间件、时序行为引擎、数据总线架构，专门探讨如何将未成年人分层风控作为独立模块，嵌入现有风控体系。同样，本文只讨论系统分层设计思路，不涉及任何可直接落地的量化阈值与核心判定算法。

一、法规对未成年人的三条硬性工程约束

《办法》第十四条及相关条款，对未成年人防护提出了三条必须通过工程手段实现的强制要求。

第一条，禁止未成年人创建或使用虚拟恋人、专属陪伴类Agent。这不是前端展示层面的限制，而是要求产品在系统底层对特定类型的Agent做刚性拦截。

第二条，未成年人模式需包含多项强制能力：单日交互时长限制、深夜时段自动切断情感交互、定期推送现实引导提示。这些能力需要独立的定时任务和触发逻辑来支撑。

第三条，未成年人交互数据需全量留存，并建立监护人可查询的审计看板。日志需要独立归档，支持按时间、行为类型快速筛选，以满足监管抽查的调阅需求。

二、当前三种常见的错误实现

在对多家团队的排查中，我总结了三种高频出现的未成年人防护误区，这些误区恰好对应了前几篇文章中拆解过的补丁式风控缺陷。

第一种，仅前端弹窗校验。用户在注册页面自行选择年龄，前端根据选择结果决定是否展示某些功能。但底层API接口没有任何年龄校验逻辑，通过抓包重放、直接调用接口的方式，可以轻松绕过前端的全部限制。这就是之前分析过的“前端拦截与底层接口断层”问题在未成年人场景下的复现。

第二种，只拦截用户输入的Prompt，不约束AI自身的输出。即便禁止用户创建“恋人”角色，已创建的普通角色在对话过程中，模型依然可能自主生成“我会永远陪着你”等软性亲密话术。这是“AI输出管控缺失”问题在特定人群场景下的延伸。

第三种，未成年人数据与普通用户日志混合存储。当监管要求调取某个未成年用户的完整交互记录时，需要从海量混杂日志中手动筛选，无法快速形成完整的审计链路。这是“数据孤岛”问题的具体体现。

三、将未成年人防护接入现有风控中间件

在前几篇文章中，我拆解了一套四层流水线架构的风控中间件：请求网关层负责统一拦截，基础规则校验层负责固定话术过滤，情绪分级约束层负责评估输出内容的情绪浓度，审计埋点输出层负责生成标准化审计日志。未成年人防护模块，可以作为一个独立的分流分支，嵌入这套现有架构的网关层。

整个分流逻辑包含五层设计。

第一层，前置年龄校验层。 在用户请求进入风控流水线之前，先进行年龄判定。判定采用多维度融合方案：实名信息、运营商年龄核验、用户行为未成年识别模型。依据识别置信度，匹配梯度化管控策略。对于高置信度的未成年人，直接执行最严格的管控等级。

第二层，Agent创建拦截分支。 当用户发起创建自定义Agent的请求时，系统对其填写的Prompt文本进行前置校验。如果识别出恋人、专属伴侣、深度绑定类人格设定，直接熔断创建请求，返回预设的拒绝话术。这套校验逻辑与基础规则校验层共享规则配置，但触发节点前置到创建环节。

第三层，会话动态约束分支。 已确认的未成年人用户，其所有对话请求进入风控中间件后，需要执行额外的动态约束逻辑。时序行为引擎统计该用户的单日累计交互时长、当前时段是否属于深夜管控区间、连续情感倾诉轮次等指标。当触发约束条件时，系统自动压缩AI的情感表达浓度，或直接切断情感交互通道，强制插入现实引导提示。

第四层，专属审计埋点。 未成年人用户的所有行为数据，需要独立写入一条隔离的数据总线。创建Agent的请求和结果、每次对话的情绪分级判定、每次干预触发的类型和时间，都以标准化的审计事件格式写入这条独立链路。当监管或监护人需要调取数据时，只需查询专属数据流，即可快速生成完整的审计报告。

第五层，极端情绪干预分支。 当系统检测到未成年人用户出现抑郁、自伤、暴力倾向等极端表述时，不执行常规的分级干预策略，而是直接触发最高等级的熔断响应，同时向预设的监护人联系方式推送预警信息。

注：上述各层中涉及的年龄判定具体维度、置信度分界标准、Prompt校验规则、时长阈值、深夜时段定义、干预话术模板等量化参数，属于核心落地配置，不在本文公开。

四、中小团队的轻量化分步落地

对于人力有限的中小团队，不必一步到位完成全部改造。可以分四个阶段逐步落地。

阶段一， 在现有风控网关层新增年龄分流逻辑。优先接入成熟的第三方年龄核验服务，完成对高置信度未成年人的识别，并阻断其创建高风险类型Agent的行为。这一步能快速补齐最基本的合规底线。

阶段二， 接入时序行为引擎。上线未成年人专属的时长统计、深夜交互自动约束能力。时长阈值和深夜时段的定义，可根据监管要求和产品实际情况做配置。

阶段三， 搭建独立的未成年人审计数据看板。将阶段一和阶段二中采集的各类行为数据，统一接入独立的审计事件总线，支持按时间、行为类型快速检索，满足监管抽查的基本要求。

阶段四， 完整上线监护人权限管理、风险消息推送等高级功能。这一阶段可以根据产品实际需求做定制化开发。

五、结语

未成年人防护不是风控系统的附加功能，而是风控中间件的原生分层能力。它需要在网关层做独立分流，在数据层做隔离存储，在干预层做专属策略。把这一层从业务代码中剥离，成为中间件的原生组成部分，后续无论是适配监管规则的变化，还是扩展新的防护能力，都具备良好的扩展性。

本系列前文已拆解通用风控中间件、AI输出四层流水线、UGC智能体整改案例，可移步专栏查看完整内容。下一篇将更新风控中间件的高并发熔断与性能调优工程实践，欢迎持续关注。

你们项目当前未成年人风控是仅做前端弹窗，还是已接入底层中间件分流？欢迎在评论区交流落地经验。