xslandCursor
2934954eb2
表名、配额种子和字段名以产品方案与架构为准；文档仓库补 .gitignore，避免 git add -A 把 API Key 推进远端。 Co-authored-by: Cursor <cursoragent@cursor.com>
432 lines
26 KiB
Markdown
432 lines
26 KiB
Markdown
# 「美搭」合规与安全方案
|
||
|
||
> 版本：**v1.3** ｜ 更新日期：2026-08-14 ｜ 状态：待法务/合规复核
|
||
>
|
||
> **为什么这份文档单独存在**：本产品同时踩在三条监管线上——处理**人脸信息**（敏感个人信息）、提供**生成式 AI 服务**、产出**AI 生成合成内容**。这三条线各自有独立的法定义务，把它们混在技术文档里会被当成技术细节忽略，所以单独成文。
|
||
>
|
||
> **状态提示（2026-08-13）**：三条主线中，主线二（生成式 AI 服务备案）**已办结** —— 原本 2~4 个月的审批周期不再是上线瓶颈。但备案完成不等于合规完成：**主线一（人脸）与主线三（AI 标识）的义务全部是工程实现要求，一项都没有减少**，且备案本身还留下四项持续义务（见 §2.2.0）。这份文档的价值不因备案完成而下降。
|
||
>
|
||
> **本文不是法律意见**。所列条款为公开法规的工程化解读，正式上线前应经法务确认，并与属地网信部门核实具体材料要求（各地执行标准不一致）。
|
||
|
||
---
|
||
|
||
## 1. 适用法规清单
|
||
|
||
| 法规 | 施行时间 | 与本产品的关系 |
|
||
| --- | --- | --- |
|
||
| 《个人信息保护法》 | 2021-11-01 | 全部个人信息处理活动的基础法 |
|
||
| 《人脸识别技术应用安全管理办法》（网信办、公安部令第 19 号） | **2025-06-01** | 拍照分析涉及人脸信息处理 |
|
||
| 《生成式人工智能服务管理暂行办法》 | 2023-08-15 | 报告文案、Agent 对话属生成式 AI 服务 |
|
||
| 《互联网信息服务算法推荐管理规定》 | 2022-03-01 | 个性化推荐 + 算法备案义务 |
|
||
| 《互联网信息服务深度合成管理规定》 | 2023-01-10 | 换装/发型属深度合成，含标识与日志义务 |
|
||
| 《人工智能生成合成内容标识办法》（四部门） | **2025-09-01** | 全部 AI 产出物的标识义务 |
|
||
| GB 45438-2025《网络安全技术 人工智能生成合成内容标识方法》 | 配套国标 | 隐式标识的技术实现依据 |
|
||
| 《未成年人网络保护条例》 | 2024-01-01 | 年龄识别与功能限制 |
|
||
| 《网络安全法》《数据安全法》 | — | 安全等级保护与数据分类分级 |
|
||
| 《广告法》 | — | 效果宣传不得绝对化 |
|
||
|
||
---
|
||
|
||
## 2. 三条主线的义务与落地
|
||
|
||
### 2.1 主线一：人脸信息处理
|
||
|
||
#### 2.1.1 法定义务
|
||
|
||
| 义务 | 条款要点 | 我们的做法 |
|
||
| --- | --- | --- |
|
||
| **单独同意** | 处理敏感个人信息须取得单独同意，不得与其他授权捆绑 | 独立的人脸授权页，单独勾选与确认。拒绝后仍可用问卷降级路径（`FR-RPT-11`） |
|
||
| **告知义务** | 告知处理目的、方式、保存期限、影响 | 授权页明示：仅用于生成你的形象报告；分析后立即删除原图；不用于识别身份；不共享给第三方用于其他目的 |
|
||
| **最小必要** | 不得超出必要范围收集 | 只要一张正面照 + 可选全身照；不采集身份证、不做人脸比对与身份识别 |
|
||
| **不得强制** | 不得以人脸作为唯一验证方式 | 登录不用人脸；人脸仅用于报告功能 |
|
||
| **PIA 评估** | 需开展个人信息保护影响评估并留存 | 上线前完成 PIA 报告（`CR-10`） |
|
||
| **备案** | 存储人脸信息达 **10 万人**时，自达到之日起 30 个工作日内向省级以上网信部门备案（线上系统 `grxxbh.cacdtsc.cn`） | **架构上规避**：见下 |
|
||
| 变更/终止 | 备案信息实质变更或终止应用，30 个工作日内变更或注销备案 | 纳入合规运维清单 |
|
||
|
||
#### 2.1.2 「原图不落盘」的完整设计
|
||
|
||
这是本产品最重要的一个合规设计决策：**通过架构使「存储的人脸信息数量」恒为 0**，从而不触发 10 万人备案阈值，同时把数据泄露的风险面降到最小。
|
||
|
||
```
|
||
用户拍照
|
||
│ ① 客户端压缩（不上传原始大图）
|
||
▼
|
||
② 预签名直传 → COS 临时桶 cos://meida-temp/
|
||
│ · 桶级生命周期：2 小时自动删除（兜底）
|
||
│ · 服务端加密（SSE）
|
||
│ · 私有权限，仅预签名访问
|
||
▼
|
||
③ Worker 拉取 → 内存中处理
|
||
│ · 内容审核
|
||
│ · 分割 / 关键点 / 属性 / 色值采样
|
||
│ · 体型与季型测算
|
||
▼
|
||
④ 输出**派生特征**（不可反推人脸）
|
||
│ 例：{"skin_lab":[68.2,12.4,18.7], "body_shape":"X", "face_shape":"椭圆"}
|
||
▼
|
||
⑤ **显式删除临时对象**（不等生命周期）
|
||
▼
|
||
⑥ 落库：仅派生特征 + 图片元信息（尺寸、时间、质量评分）
|
||
```
|
||
|
||
**明确的红线**：
|
||
|
||
| 禁止 | 原因 |
|
||
| --- | --- |
|
||
| 将人脸原图写入用户内容桶或数据库 | 会形成人脸信息存储，触发备案义务与更高安全要求 |
|
||
| 存储人脸特征向量（faceprint/embedding） | 属可用于识别特定自然人的生物识别信息，风险等级等同原图 |
|
||
| 存储 888 点稠密关键点原始坐标 | 精度足以重建面部轮廓，视为生物识别信息。只保留**归一化比例与分类结论** |
|
||
| 在日志、监控、错误上报中打印图片 URL 或人脸数据 | 日志系统的访问控制通常弱于业务库 |
|
||
| 将人脸数据传给未签署数据处理协议的第三方 | 需有委托处理协议与安全评估 |
|
||
|
||
**换装结果图的定性**：结果图包含用户面部，属个人信息，但它是**用户主动生成并选择保存的内容**，存于用户内容桶，随账号注销删除，用户可随时单独删除。它不进入「用于人脸识别技术的人脸信息存储」范畴，但仍需私有桶 + 签名访问 + 防盗链保护。
|
||
|
||
#### 2.1.3 第三方处理者管理
|
||
|
||
人脸数据会传给腾讯云（分割、人脸属性与关键点）与自有换装服务：
|
||
|
||
| 接收方 | 数据 | 要求 |
|
||
| --- | --- | --- |
|
||
| 腾讯云人脸识别/人体分析 | 照片（API 调用） | 签署云服务协议与数据处理条款；在隐私政策中披露；确认其不留存 |
|
||
| 自有换装服务 | 照片 + 单品图 | 内网隔离；处理后不留存原图；纳入同一套安全要求 |
|
||
| 大模型服务商 | **不传人脸图片** | 只传派生的结构化特征与文本，图片不出我们的边界（V2 图片理解功能需重新评估并单独告知） |
|
||
|
||
**隐私政策中必须有一张「第三方共享清单」**，列明接收方、数据类型、目的、方式。这是上架审核会查的项。
|
||
|
||
### 2.2 主线二：生成式 AI 服务备案（✅ 已完成，转为持续义务）
|
||
|
||
> **状态更新（2026-08-13）**：**备案已办结**。原本 2~4 个月的外部审批周期不再是上线瓶颈，本节的重心从「如何办下来」转为「**办下来之后要持续做什么**」。
|
||
>
|
||
> #### 2.2.0 备案完成后的四项持续义务
|
||
>
|
||
> | # | 义务 | 具体要求 | 落点 |
|
||
> |---|------|---------|------|
|
||
> | 1 | **编号界面公示** | 在 App 显著位置公示模型名称与备案编号 | §2.2.4，`CR-08` |
|
||
> | 2 | **备案范围与实际调用一致** | ⚠️ **最需要核实的一条**。实际调用的模型清单必须与备案登记的一致 | 见下方风险提示 |
|
||
> | 3 | **变更备案** | 新增模型、变更服务功能或算法机制后，**30 个工作日内**办理变更 | §6 持续合规运维 |
|
||
> | 4 | **材料维护** | 安全自评估报告、拦截关键词库、评估测试题集、测试通道与虚拟账号需持续可用 | §2.2.2、§6 |
|
||
>
|
||
> ⚠️ **唯一的开放风险 —— 备案覆盖的模型清单**
|
||
>
|
||
> 架构上选定的是 **DeepSeek 主 + 智谱 GLM 备/视觉** 的双路由方案（`TD-04`）。**如果备案登记时只申报了其中一家，上线双路由即属超范围提供服务。**
|
||
>
|
||
> 处理方式（按优先顺序）：
|
||
> 1. 核实备案材料中申报的模型清单
|
||
> 2. 若已覆盖两家 → 无需动作
|
||
> 3. 若只覆盖一家 → **V1 先只启用已登记的那一家**，同时启动变更备案。LLM 网关已做多路由抽象（§8.1），切换是配置级改动，不影响排期
|
||
>
|
||
> **不建议靠推测处理**：超范围提供服务的后果远大于少用一个备用模型带来的可用性损失。
|
||
|
||
#### 2.2.1 路径判定（保留，作为变更备案的判定依据）
|
||
|
||
```
|
||
我们是否自研或微调模型？── 否（仅调用 DeepSeek/GLM 官方 API）
|
||
│
|
||
▼
|
||
不需要「大模型备案」
|
||
│
|
||
▼
|
||
面向境内公众提供，具舆论属性或社会动员能力？── 是
|
||
│
|
||
▼
|
||
需要：① 大模型登记（属地网信办）✅ 已完成
|
||
② 算法备案（beian.cac.gov.cn）✅ 已完成
|
||
③ 安全自评估 ✅ 已完成
|
||
```
|
||
|
||
#### 2.2.2 材料清单（已提交，但需持续维护 —— 变更备案时会再次用到）
|
||
|
||
| 材料 | 责任方 | 提前量 | 备注 |
|
||
| --- | --- | --- | --- |
|
||
| 安全自评估报告 | 合规 + 技术 | 早 | 参照《生成式人工智能服务安全基本要求》 |
|
||
| 调用已备案大模型的情况说明 + 证明材料 | 商务 + 技术 | 早 | **需模型厂商侧的备案号与配合证明** |
|
||
| 与算法技术主体的合作协议 | 商务 | 早 | ⚠️ 若通过云厂商 MaaS 平台中转调用，云厂商**无法代第三方模型厂商出具并盖章**。**因此直接使用 DeepSeek / 智谱官方 API**，便于获取材料 |
|
||
| 产品服务协议、隐私政策 | 法务 | 早 | 需体现 AI 生成告知 |
|
||
| 内容安全管理制度 | 合规 | 中 | 审核流程、人工复核、应急处置 |
|
||
| **拦截关键词库** | 技术 + 合规 | 中 | 部分地区要求万级规模 |
|
||
| 评估测试题集 | 技术 + 合规 | 中 | 用于验证拒答与安全能力 |
|
||
| API 接口信息 + 虚拟测试账号 | 技术 | 中 | **需提供「附加审核策略」与「不附加审核策略」两种测试通道** |
|
||
| 算法安全自评估、算法机制机理说明 | 技术 | 中 | 算法备案用 |
|
||
|
||
#### 2.2.3 ~~时间线~~ → 已完成，不再影响项目节奏
|
||
|
||
原时间线（T+0 沟通 → T+1 提交 → T+3~4 取得编号 → T+4 上架）**已走完**。
|
||
|
||
**这对项目意味着什么**：原本"备案 4 个月 vs 开发 3 个月"的并行关系不再存在，**开发进度现在就是上线进度**。项目的关键路径转移到内部工序，其中最长的是**素材自采与规则库生产**（`TD-26`、`TD-27`）—— 这是唯一无法靠 AI 辅助开发压缩的部分。
|
||
|
||
**变更备案的时间线（将来可能用到）**：实质变更后须在 **30 个工作日内**办理。因此若 V2 计划新增模型，应在开发启动时同步提交变更申请，而非等功能完成。
|
||
|
||
#### 2.2.4 公示要求（**现在是必须落地的开发任务，不再是待办材料**）
|
||
|
||
浙江、江苏、安徽、陕西等地明确要求：已上线的生成式 AI 应用需在**界面显著位置**注明模型名称、备案号及服务情况。应用市场上架时也会核验。
|
||
|
||
**产品落地**：在「设置 → 关于」页面固定展示（编号已取得，可直接填入）：
|
||
```
|
||
本应用的 AI 能力由 <模型名称> 提供
|
||
大模型登记号 / 算法备案号：<编号>
|
||
AI 生成内容仅供参考，不构成专业建议
|
||
```
|
||
|
||
**三条实现要求**：
|
||
- 公示位在端上是**硬编码的固定入口**，不走服务端配置下发 —— 避免配置异常导致公示消失
|
||
- 编号内容可服务端下发（便于变更备案后更新），但**入口本身不可隐藏**
|
||
- 若展示的模型名称与实际调用不一致，等同于未公示。因此**公示文案必须与 LLM 网关的实际路由配置同源**，不允许两处各自维护
|
||
|
||
### 2.3 主线三：AI 生成内容标识
|
||
|
||
#### 2.3.1 覆盖对象
|
||
|
||
| 产物 | 类型 | 显式标识 | 隐式标识 |
|
||
| --- | --- | --- | --- |
|
||
| 换装结果图 | 图片 | 画面内可见「AI 生成」 | EXIF/XMP 元数据 |
|
||
| 发型效果图 | 图片 | 同上 | 同上 |
|
||
| 报告长图 | 图片 | 首屏与分享图均标识 | 同上 |
|
||
| 报告 PDF | 文档 | 页内标识 | 文档元数据 |
|
||
| Agent 回复 | 文本 | 会话界面固定提示 | 交互场景以界面提示为主 |
|
||
| 报告文案 | 文本 | 报告内提示 | 随长图元数据 |
|
||
|
||
#### 2.3.2 隐式标识的字段要求
|
||
|
||
按办法第五条，文件元数据中需包含：
|
||
|
||
| 字段 | 内容 |
|
||
| --- | --- |
|
||
| 生成合成内容属性信息 | 标明为 AI 生成合成内容（属性标签：明确/可能/疑似） |
|
||
| 服务提供者名称或编码 | 按《服务提供者编码规则》实践指南取得/生成 |
|
||
| 内容编号 | **27 位数字或大写字母**，全局唯一，登记入 `cp_content_registry` |
|
||
|
||
内容编号生成方案（需与国标编码规则最终核对）：
|
||
|
||
```
|
||
27 位 = 服务提供者编码段 + 时间段 + 序列段（Base32 大写字母与数字，无易混字符）
|
||
生成即登记，可反查：内容编号 → 生成时间、模型、场景、关联业务 ID
|
||
```
|
||
|
||
#### 2.3.3 最容易踩的坑：元数据被剥离
|
||
|
||
**这是本项目在合规上最可能出问题的地方**，因为它不会报错，只会静默失效：
|
||
|
||
| 环节 | 风险 | 必须验证 |
|
||
| --- | --- | --- |
|
||
| CDN 图片处理 | 缩放/压缩/格式转换常剥离 EXIF/XMP | 关闭图片处理的元数据剥离，或对原图与派生图分别处理 |
|
||
| 客户端保存到相册 | 系统相册可能重编码 | 保存后读回验证元数据 |
|
||
| 用户分享到第三方平台 | 平台会重编码，元数据必失 | 无法控制，但**显式水印必须保留在画面内**——这就是为什么显式标识不能只做界面提示 |
|
||
| 服务端二次处理（加水印） | 处理库默认丢弃元数据 | 水印与元数据写入必须在**同一个处理步骤的末尾**完成 |
|
||
|
||
**验收要求（`CR-05`）**：编写一个自动化测试，覆盖「生成 → 加水印 → 上传 COS → CDN 分发 → 客户端下载 → 保存相册 → 读回」全链路，断言元数据字段存在。
|
||
|
||
#### 2.3.4 显式标识的设计要求
|
||
|
||
不只是「加个水印」这么简单，要考虑被规避的情况：
|
||
|
||
- 位置：不放在图片边缘（容易被裁掉），放在画面内相对固定的安全区
|
||
- 对比度：保证在任意背景上可辨识
|
||
- 分享图：分享用的长图/卡片必须**独立确认**标识存在（这是最容易漏的路径）
|
||
- **V1 不提供「去除显式标识」的功能**——办法允许用户申请去除，但需签订协议并留存日志至少 6 个月，额外增加义务，V1 不值得
|
||
|
||
### 2.4 内容审核
|
||
|
||
#### 2.4.1 审核矩阵
|
||
|
||
| 对象 | 时机 | 工具 | 失败处理 |
|
||
| --- | --- | --- | --- |
|
||
| 用户上传照片 | 分析前 | 腾讯云 IMS | 拒绝并提示，不消耗点数 |
|
||
| 换装/发型结果图 | 返回前 | IMS | 拦截，任务标记失败并**退还配额** |
|
||
| 用户对话输入 | 送 LLM 前 | 腾讯云 TMS + 自有关键词库 | 返回安全提示，记录日志 |
|
||
| LLM 输出 | 返回前 | TMS | 重新生成（最多 2 次）或返回兜底话术 |
|
||
| 报告文案与长图 | 发布前 | TMS + IMS | 降级为模板文案 |
|
||
| 运营录入的知识内容 | 发布前 | 机审 + 人工双轨 | 打回修改 |
|
||
| 用户昵称、头像 | 保存时 | TMS + IMS | 拒绝保存 |
|
||
|
||
#### 2.4.2 fail-close 原则
|
||
|
||
**审核服务不可用时，一律按「拦截」处理。** 这与其他外部依赖的 fail-soft 策略相反，是有意为之：漏审一条违规内容的代价（下架、处罚）远高于短时间功能不可用。
|
||
|
||
实现要求：审核调用失败要与「审核判定为违规」区分记录，前者告警（需要运维介入），后者是正常业务流。
|
||
|
||
#### 2.4.3 关键词库
|
||
|
||
- 来源：备案要求的拦截词库 + 行业通用敏感词 + 本产品特有边界词（医疗、命理、身材贬损、他人评价）
|
||
- 承载：腾讯云 TMS 自定义关键词库（单次最多 2000 个，需分批维护）+ 本地词库兜底
|
||
- 维护：后台可维护，变更留审计；命中记录留存
|
||
|
||
### 2.5 未成年人保护
|
||
|
||
| 要求 | 落地 |
|
||
| --- | --- |
|
||
| 年龄判定 | 注册时采集年龄段；华为账号提供未成年人模式信号时优先采用 |
|
||
| 功能限制 | 未成年账号：禁用付费、禁用外观评价类内容、报告表述更保守 |
|
||
| 监护提示 | 明确提示需监护人知情同意 |
|
||
| 内容分级 | 涉及身材、体型的表述对未成年人使用更谨慎的措辞 |
|
||
|
||
---
|
||
|
||
## 3. 内容伦理红线（产品自律，高于法规）
|
||
|
||
这类产品最容易造成的伤害不是数据泄露，而是**对用户外观的评判造成心理伤害**。以下是写进 Prompt 与规则库的硬约束：
|
||
|
||
| 红线 | 反例（禁止） | 正例（要求） |
|
||
| --- | --- | --- |
|
||
| 描述而非评判 | 「你的脸型有点大，不好看」 | 「你的脸型轮廓偏圆润，适合有一定纵向线条的发型来延展视觉比例」 |
|
||
| 不使用缺陷框架 | 「腿短是你的缺点」 | 「上下身比例接近 1:1.2，通过提高腰线可以让腿部比例视觉上更修长」 |
|
||
| 不做医疗判断 | 「你的皮肤有问题，建议就医」「你需要减肥」 | 不涉及。转向穿搭与色彩建议 |
|
||
| 不做绝对化承诺 | 「按这个搭配一定显瘦 10 斤」 | 「这个搭配有助于视觉上拉长身形」 |
|
||
| 不评价他人 | 对用户上传的他人照片做评价 | 拒答并说明只服务本人形象 |
|
||
| 不做身份推断 | 推断收入、职业层级、地域并据此差异化表述 | 不做 |
|
||
| 尊重多样性 | 暗示某种体型/肤色更优 | 每种特征都给出正向的搭配路径 |
|
||
|
||
**技术落点**：这些约束同时写入三处，缺一处就会漏——① 系统 Prompt；② 规则库的硬约束（禁忌用词表）；③ 生成后校验（贬损词检测）。
|
||
|
||
---
|
||
|
||
## 4. 数据安全
|
||
|
||
### 4.1 数据分类分级
|
||
|
||
| 级别 | 数据 | 存储要求 | 访问要求 |
|
||
| --- | --- | --- | --- |
|
||
| **L4 敏感个人信息** | 人脸原图 | **不持久化**（临时桶 ≤ 2h） | 仅 Worker 进程内，预签名短期 |
|
||
| **L3 重要个人信息** | 诊断结论、体型/季型标签、结果图 | 加密存储，私有桶 | 严格归属校验，日志脱敏 |
|
||
| **L2 一般个人信息** | 昵称、头像、UnionID、设备信息 | 常规加密 | 归属校验 |
|
||
| **L1 业务数据** | 知识库、规则、色板 | 常规 | 后台权限 |
|
||
| **L0 公开** | 产品配置、文案 | — | — |
|
||
|
||
### 4.2 安全措施清单
|
||
|
||
| 领域 | 措施 |
|
||
| --- | --- |
|
||
| 传输 | 全链路 HTTPS/TLS 1.2+；证书自动续期 |
|
||
| 存储 | COS 服务端加密；数据库敏感字段加密；备份加密 |
|
||
| 密钥 | SSM/KMS 集中管理；禁止进代码、镜像、明文环境变量；定期轮换 |
|
||
| 访问控制 | 最小权限；后台独立账号体系与网段；生产数据库禁止直连（走跳板与审计） |
|
||
| 越权防护 | 所有资源访问校验 `user_id` 归属；越权用例进自动化测试 |
|
||
| 日志 | 脱敏中间件（手机号、UnionID、图片地址、诊断结论）；审计日志独立留存 ≥ 6 个月 |
|
||
| 图片访问 | 私有桶 + 短期签名 URL + CDN 防盗链 + Referer 校验 |
|
||
| 防刷 | 设备指纹、频控、异常注册识别、**配额硬限制**、**短信通道防刷**（`FR-ACC-14`） |
|
||
| Prompt 注入 | 用户内容与系统指令严格分区；输出侧校验；用户内容不得触发工具调用决策 |
|
||
| 漏洞管理 | 依赖漏洞扫描进 CI；密钥泄露扫描 pre-commit |
|
||
| 应急 | 数据泄露应急预案 + 联系人 + 上报流程（法定 72 小时内通知义务） |
|
||
|
||
### 4.3 数据生命周期
|
||
|
||
| 数据 | 保留期 | 删除触发 |
|
||
| --- | --- | --- |
|
||
| 人脸原图 | ≤ 2 小时（实际处理完即删） | 处理完成 / 桶生命周期 |
|
||
| 报告与诊断结论 | 账号存续期间 | 用户删除 / 注销后 7 日内 |
|
||
| 换装结果图 | 账号存续期间 | 用户删除 / 注销后 7 日内 |
|
||
| 对话原文 | 90 天 | 到期自动清理 |
|
||
| 对话摘要（L3/L4 记忆） | 180 天 | 到期或用户删除 |
|
||
| 审核日志、生成记录 | ≥ 6 个月（法定） | 到期归档 |
|
||
| 埋点事件 | 12 个月 | 分区滚动删除 |
|
||
| 审计日志 | 24 个月 | — |
|
||
|
||
**注销的删除必须是真删除**：包括数据库记录、COS 对象、缓存、备份中的可识别数据（备份按周期自然滚动，需在隐私政策中说明备份滚动周期）。删除任务本身要有执行记录以证明履行义务（`FR-ACC-09`）。
|
||
|
||
---
|
||
|
||
## 5. 上线前合规检查清单
|
||
|
||
> 这份清单是上线的门禁。每一项都要有责任人和证据。
|
||
|
||
### 5.1 资质与备案
|
||
|
||
- [x] 企业主体资质、ICP 备案
|
||
- [x] **大模型登记号取得**
|
||
- [x] **算法备案号取得**
|
||
- [x] 安全自评估报告归档
|
||
- [x] 与模型厂商的合作证明材料齐备
|
||
- [ ] ⚠️ **核实备案覆盖的模型清单是否含 DeepSeek + 智谱 GLM 两家**（见 §2.2.0，唯一开放项）
|
||
- [ ] **界面显著位置公示模型名称与编号**（编号已取得，待端上实现，见 §2.2.4）
|
||
- [ ] 公示文案与 LLM 网关实际路由配置同源校验
|
||
- [ ] ~~华为企业开发者认证~~ —— **V1 不需要**：不接 IAP，一键登录降级 V2（`TD-29`）
|
||
|
||
### 5.2 文档与协议
|
||
|
||
- [ ] 用户协议（含 AI 生成告知、免责边界）
|
||
- [ ] 隐私政策（含第三方共享清单、数据保留期、用户权利行使方式）
|
||
- [ ] 人脸信息单独同意文案
|
||
- [ ] 未成年人保护声明
|
||
- [ ] PIA 个人信息保护影响评估报告
|
||
- [ ] 内容安全管理制度
|
||
- [ ] 数据泄露应急预案
|
||
|
||
### 5.3 功能验证
|
||
|
||
- [ ] 人脸原图处理后确实删除（抽查临时桶无残留）
|
||
- [ ] 人脸单独同意为独立页面，拒绝后降级路径可用
|
||
- [ ] 所有生成物含显式标识（含分享图路径）
|
||
- [ ] 隐式元数据全链路存活测试通过（CDN → 客户端 → 相册）
|
||
- [ ] 输入输出双向审核全部生效
|
||
- [ ] 审核服务不可用时 fail-close 生效
|
||
- [ ] 关键词拦截库生效并可维护
|
||
- [ ] 未成年账号功能限制生效
|
||
- [ ] 注销流程 7 日内彻底删除，且有执行记录
|
||
- [ ] 越权访问测试全部拦截
|
||
- [ ] 日志中无敏感信息（人工抽查 + 自动扫描）
|
||
- [ ] **生产环境确认无 `dev-token` 路由**（`DEV_AUTH_ENABLED` 与 `is_local` 双开关均须为关；发布包探测 `/api/v1/auth/dev-token` 应 404）
|
||
- [ ] 越界问题（医疗/命理/他人评价）拒答测试通过 —— **命理模块已决定不做（`TD-31`），但对话侧仍须拒答**
|
||
- [ ] 贬损性表述检测生效（用负面样本集验证）
|
||
- [ ] 备案编号公示位在发布包中可见且内容正确
|
||
- [ ] ~~支付与交易类合规项~~ —— **V1 不涉及**（无 IAP、无订单、无退款，`TD-28`）
|
||
|
||
### 5.4 运营准备
|
||
|
||
- [ ] 人工复核值班机制（审核申诉处理）
|
||
- [ ] 用户投诉与个人信息权利请求受理渠道
|
||
- [ ] 合规运维日历（备案变更、协议版本更新、日志归档）
|
||
|
||
---
|
||
|
||
## 6. 持续合规运维
|
||
|
||
> **备案完成后，本节从"将来要做的事"变成"现在就要执行的事"** —— 这是备案完成带来的责任转移，容易被忽略。
|
||
|
||
| 事项 | 频率 | 责任 |
|
||
| --- | --- | --- |
|
||
| **备案信息实质变更后办理变更** | 变更后 **30 个工作日内** | 合规 |
|
||
| **备案范围与实际调用模型的一致性核对** | **每次发版前** | 技术 + 合规 |
|
||
| **公示编号与模型名称的正确性检查**（含发布包实机验证） | 每次发版前 | 技术 |
|
||
| 人脸信息存储量监控（若策略变更导致开始存储） | 月度 | 技术 |
|
||
| 关键词库更新 | 月度 | 合规 |
|
||
| 审核准确率抽检（误杀与漏放） | 月度 | 运营 |
|
||
| 隐私政策与协议版本复审 | 季度 | 法务 |
|
||
| 法规跟踪（新规与征求意见稿） | 季度 | 合规 |
|
||
| 数据删除任务执行审计 | 季度 | 技术 |
|
||
| 备份恢复演练 | 半年 | 技术 |
|
||
| 安全渗透测试 | 年度 | 技术 |
|
||
|
||
**特别关注的立法动向**：《人工智能拟人化互动服务管理暂行办法》已进入公开征求意见阶段，其中包含分发平台核验义务与算法备案年度复审要求。本产品的 Agent 具备拟人化互动特征，若该办法正式施行，需重新评估适用性。
|
||
|
||
---
|
||
|
||
## 7. 与其他文档的对应
|
||
|
||
| 本文内容 | 对应 |
|
||
| --- | --- |
|
||
| 全部义务的需求化 | 《需求规格说明》CR-01 ~ CR-12 |
|
||
| 原图不落盘的工程实现 | 《技术架构文档》§7.1、§11.2 |
|
||
| 统一合规出口 | 《技术架构文档》§7.5 |
|
||
| 备案时间线对项目的影响 | 《开发任务拆解》Phase 0 |
|
||
| 内容伦理红线的规则落地 | 《美学知识库-建设方案》规则库 + 《美学报告-需求文档》§9 |
|
||
|
||
---
|
||
|
||
## 相关文档
|
||
|
||
- [文档索引](./README.md)
|
||
- [需求规格说明](./需求规格说明.md)（本文义务对应 `CR-01`~`CR-12`，不可裁剪、不可降级）
|
||
- [技术架构文档](./技术架构文档.md)（§7.5 统一合规出口、§11 安全设计）
|
||
- [技术选型与调研报告](./技术选型与调研报告.md)（§5 合规与法务，含选型对备案的影响）
|
||
- [开发任务拆解](./开发任务拆解.md)（Phase 0 为备案与合规前置阶段）
|
||
|
||
---
|
||
|
||
## 变更记录
|
||
|
||
| 日期 | 版本 | 变更 |
|
||
| --- | --- | --- |
|
||
| 2026-08-14 | v1.3 | §5.3 补「生产环境确认无 `dev-token` 路由」 |
|
||
| 2026-08-13 | v1.2 | **文档一致性评审修订**。**本文的「人脸原图保留期 ≤ 2 小时」被确认为全局唯一事实源** —— 产品方案 §7.1.4 与美学报告 §9.1 原写「≤ 24h 仅用于任务重试」，已按本文更正（2 小时已足够覆盖重试窗口：最长任务 320s、重试上限 3 次；24h 只是白担合规风险，保留期越长越可能被认定为"存储了人脸信息"从而触发 10 万人备案义务）。§5.3 检查清单补入 `FR-ACC-15`「清空我的照片」（涉及人脸数据删除，此前无 FR 也未纳入清单）；防刷项补入配额硬限制与短信通道防刷（`FR-ACC-14`）；措辞「退点」→「退还配额」 |
|
||
| 2026-08-13 | v1.1 | **主线二状态更新为「备案已完成」**。新增 §2.2.0「备案完成后的四项持续义务」（编号公示、备案范围与实际调用一致、变更备案 30 工作日、材料维护），并标出唯一开放风险 —— 备案覆盖的模型清单是否含 DeepSeek + GLM 两家，若只含一家则双路由属超范围。§2.2.3 时间线改为已完成说明，指出关键路径已转移到素材与规则库生产。§2.2.4 公示要求从"待办材料"升为"必须落地的开发任务"，补充三条实现要求（入口硬编码、编号可下发、文案与网关路由同源）。§5.1 检查清单标记已完成项，移除华为企业开发者认证（V1 不需要）；§5.3 移除支付类合规项 |
|
||
| 2026-08-13 | v1.0 | 首次输出。确立三条主线：① 人脸原图不落盘以规避 10 万人备案阈值；② 大模型登记 + 算法备案须在 Phase 0 启动（周期 2~4 个月）；③ AI 生成内容显式 + 隐式双重标识，经统一合规出口收口 |
|