算法安全自评估报告重难点拆解

维度一：算法基本信息

要写什么

这一块是报告的开篇，需要把算法的全貌交代清楚：

- 算法名称：与备案系统填报完全一致，建议格式为"品牌名+功能+算法"

- 算法类型：从五类中选一类，说清楚判定依据

- 功能描述：这个算法具体做什么，输入什么、输出什么

- 应用场景：用在哪些产品功能上，用户在什么情况下会触碰到它

- 技术原理：核心模型架构（如Transformer、扩散模型）、参数规模、训练框架

- 模型架构图：从输入到输出的完整技术链路

- 数据流转图：数据从采集、处理、训练、推理到输出的全生命周期

常见问题

问题一：架构图和数据流转图混在一起。 这两张图要分开画。架构图展示技术组件（模型结构、服务部署、网关），数据流转图展示数据的物理流动路径（数据从哪来、经过哪些处理环节、最终存在哪、保存多久）。

问题二：技术原理写成了论文综述。 审核人员不是来看你的模型有多先进的，他们要看的是算法的输入输出能力和潜在风险面。写清楚"输入什么→模型做了什么→输出什么"就够了，不需要展开推导过程。

维度二：数据来源合法性

要写什么

- 数据来源分类：公开数据集、自采数据、第三方采购、用户生成内容，每类占比多少

- 版权证明：每种来源的授权许可或采购合同编号

- 脱敏/去标识化措施：涉及个人信息的数据做了哪些处理

- 数据存储：存在哪里（物理位置、存储方式）、保存多久、到期怎么销毁

- 数据标注：如果有人工标注，标注团队是自建还是外包、标注规范是什么、质检机制是什么

常见问题

问题一：只写"数据来源合法"四个字。 这是最常见的被打回的原因。监管要的不是结论，是过程——你得证明你怎么确保它是合法的。每类数据来源都要单独列出来，附上授权依据。

问题二：忽略用户生成内容的合规处理。 如果你的训练数据中有用户上传的内容，需要说明：是否取得了用户授权（用户协议中有没有相关条款）、是否做了内容安全过滤、是否脱敏处理。

问题三：存储周期含糊。 "长期保存"不是答案。要写具体的时间，如"训练数据保存5年，到期后物理删除；用户日志保存6个月，到期后自动清理。"

维度三：安全测试数据

要写什么

这是报告中数据量最大的部分，有三组硬指标：

每一项都需要附上：

- 测试样本的抽样方法（怎么选的这4000条）

- 测试标准（什么算"合格"，什么算"不合格"）

- 具体的测试结果数值（不是"合格率达标"，而是"4000条中合格3850条，不合格150条，合格率96.25%"）

- 不合格样本的处理措施（删除？修正？重新训练？）

常见问题

问题一：安全测试数据不足。 有些企业提交报告时，测试还没做完，只写了个预估数。审核人员要看实际数据，预估值不被接受。

问题二：测试覆盖面不够。 300条敏感问题不能全是同一类型。必须覆盖：政治敏感类、暴力犯罪类、色情低俗类、歧视性言论类（种族/性别/地域）、虚假信息类。每类至少几十条，不能偏科。

问题三：拒答率不达标就提交。 如果模型拒答率只有80%，别硬提交。先优化模型（加RLHF训练、调整系统提示词、增加安全过滤层），跑到95%以上再提交。否则第一次被打回，第二次提交时审核人员会更严格。

问题四：测试用例太弱。 直接用网上的公开prompt列表，很容易被判定为不够。建议参考CValues、SafetyBench等学术基准，结合自身产品场景定制测试用例。

维度四：风险防控措施

要写什么

针对法规明确禁止的行为，逐条说明技术防控措施：

1. 诱导沉迷：有没有使用时长限制、休息提醒机制

2. 大数据杀熟：算法是否存在基于用户画像的差异化定价

3. 操纵榜单：排序逻辑是否透明、能否被人为操控

4. 歧视性内容：模型输出是否存在种族、性别、地域等歧视性言论

5. 虚假信息：模型是否会生成虚假新闻、谣言

6. 未成年人保护：是否识别未成年人用户、是否有特殊内容过滤

每一条不能只写"有防控措施"，要写清楚：

- 风险点是什么（具体描述）

- 怎么检测的（技术手段）

- 怎么拦截的（拦截机制）

- 拦截后怎么处理的（兜底回复、用户提示等）

- 效果数据（拦截率多少、误拦率多少）

常见问题

问题一：防控措施笼统。 "我们使用敏感词过滤系统来防范风险"——这种写法100%被驳回。要写：敏感词库有多少个词、覆盖哪些类别、匹配算法是什么（精确匹配/模糊匹配/语义匹配）、命中后怎么处理（拦截/替换/人工审核）。

问题二：没有效果数据。 写了一堆措施，但不说效果。审核人员要看的是：你的措施实际拦截了多少违规内容、拦截率多少、有没有误拦正常内容。没有数据支撑的措施等于没有措施。

维度五：算法可解释性

要写什么

- 决策逻辑说明：算法的核心决策路径是什么，输入到输出中间经过了哪些处理环节

- 特征权重：影响算法输出的主要因素有哪些，各占多大权重

- 输出可追溯：给定一个输出结果，能否回溯到对应的输入和决策路径

- 用户告知机制：用户是否知道自己在与AI交互，是否知道内容是AI生成的

常见问题

问题一：直接跳过这一块。 很多企业觉得"大模型的黑盒问题没法解释"，就在报告里一笔带过。这是不行的。即使是黑盒模型，你也需要说明：模型的输入预处理流程、输出后处理流程（安全过滤、格式化）、以及你对模型行为的监控机制。完全的黑盒不可解释，但"不可完全解释"不等于"完全不可解释"。

问题二：用学术术语充数。 写一堆SHAP值、LIME解释方法的专业术语，但没有结合自身产品的实际应用。审核人员要看的是你在产品中怎么实现的，不是你的理论功底。

维度六：应急响应

要写什么

- 异常监测：你怎么发现算法出了问题（自动监控指标是什么、阈值是多少）

- 应急流程：发现异常后怎么处置（谁负责响应、多长时间内处置、处置方式是什么）

- 快速下线能力：能不能在发现问题后迅速关停算法功能

- 用户投诉处理：用户投诉渠道是什么、处理时限、处理结果记录

- 事后复盘：异常事件后的复盘机制和改进措施

常见问题

问题一：只写了制度没有写了实际能力。 "我们建立了完善的应急响应机制"——然后呢？要写：监控系统监测哪些指标（如生成内容的违规率、用户投诉量、模型推理异常率）、监测频率（实时/每小时/每天）、异常触发后的响应SLA（多少分钟内人工介入、多少分钟内处置完成）。

问题二：没有历史数据。 如果产品已经上线运营过，可以附上实际的应急响应案例（脱敏后）。如果没有上线，至少要有桌面演练的记录。