深度合成引擎安全性评估标准

做数字人、换脸、语音克隆或视频生成的团队，最常卡在同一个点上：甲方或平台问「你这个引擎安全吗」，团队拿不出一份能对得上条款的说明，只能说「我们有审核」。这篇把安全性评估拆成可检查的维度、可提交的证据和可复用的复评节奏，帮你在对接客户、过平台审核和内部立项时把话讲清楚。

给深度合成技术团队讲清楚一件事：当甲方、平台审核或内部立项问「你们引擎安全吗」，你需要的不是一句「我们有审核」，而是一份能对着条款、对着证据、对着责任人把话说明白的评估表。这篇不重复法规原文，只讲评估维度怎么划、证据怎么留、什么时候复评、现场会被问倒在哪。

先立一个前提：这份评估是做给你自己团队和对接方看的，不是写给监管的申请书。所以每一栏都要落到「谁做、做了什么、留了什么记录、缺什么、什么时候补」。凡是写「应加强」「需重视」这种没法验收的表述，等于没写。

先分清评的是什么：模型、引擎还是产品

很多团队一上来就填一张大表，结果模型方给的合规声明、自己引擎的接口风控、产品层的使用场景混在一起，评审时谁也说不清哪条是谁的责任。先把三层拆开：模型能力安全、引擎工程安全、产品使用场景，各自填各自的结论，最后再叠一张调用链说明。

输入侧与输出侧的管控点怎么定

• 输入侧：上传的人脸、声音样本是否做授权校验；是否限制可指定的真实人物身份范围；提示词里出现真人姓名时走什么路径。
• 输出侧：生成内容是否带可追溯标识；元数据是否保留；命中规则时是直接拦截、降级重生成，还是转人工。
• 判定标准必须写成「什么情况下判定为不通过」，比如「未做授权校验的人脸素材不得进入生成队列」，而不是「应加强素材审核」。
• 不适用情形：纯内部生产工具、无对外入口时，输入侧可以放宽到「素材来源登记清楚即可」，但输出侧标识不能省。

1. 列输入类型把人脸、声音、视频、提示词四类输入各写一行，标注是否有授权校验和校验方式。
2. 列输出动作对每类输出写清楚：带不带标识、存不存留档、命中规则怎么处置。
3. 写不通过条件每条管控点后面跟一句「什么情况下判不通过」，让评审能直接打勾或打叉。

可追溯性：出事时能拿出哪几样证据

可追溯性不是「我们有日志」四个字能交差的。出事时对方要的是能还原单次生成的最小证据集，缺一项就得靠猜。通常包括：请求标识、生成时间、输入摘要、输出留档策略、操作主体。这五样凑齐，才叫能查。

请求标识

每次生成唯一的 ID，能串起输入、输出和操作人。

输入摘要

素材和提示词按脱敏口径存摘要，不存原文，具体口径见站内日志相关页面。

输出留档策略

写清楚留多久、能不能导出、谁能查，这三条比「有没有存」更重要。

操作主体

日志里能查到是谁触发的，否则留档等于没留。

权限与滥用防护：谁能调、调多少、异常怎么断

权限这块最容易偷懒：一个 Key 全团队通用，出事谁调的都查不出。建议按身份分层——个人试用、企业客户、内部批处理走不同凭证和不同额度口径。额度具体数字去站内价格与用量相关页面核对当时的配置，别在评估表里写死。

• 滥用信号可以观察三类：短时间高频调用、素材集中在少数身份、输出集中在敏感题材。
• 先设观察项再谈自动处置，一上来就自动封禁容易误伤正常客户。
• 不适用情形：内部离线部署、无对外接口的场景，重点从调用风控移到素材授权和产出物管理。

把技术动作映射到合规条款

合规映射最容易做成抄条款——把法规原文贴一遍，评审看不出你做了什么。正确做法是三列成表：做了什么动作、留下什么记录、对应哪条要求。深度合成场景里被追问最多的是标识、授权、可追溯这三类，逐条写出你自己的实现方式和责任分工。

平台侧和客户侧的合规口径可能不一样，出现冲突时以更严的一侧为准，并在评估表里注明差异点。这样对接时不用每次重新解释，直接指给对方看。

多久评一次：触发复评的几种情况

固定节奏之外，有四种情况必须触发复评：换底座模型、换素材来源、开放新入口、新增第三方调用方。这四种任何一个发生，旧结论都不再适用，不能拿上一版截图糊弄过去。

1. 标变更点在评估文档头部记录本次变更属于哪一类，只跑受影响的小节。
2. 重采证据受影响小节的证据必须重新采集，标注采集时间，不能沿用旧截图。
3. 写版本号把评估版本号写进文档头部，避免半年后没人说得清结论对应哪一版引擎。

复评不是重做全表，是按变更点跑受影响的小节，但证据必须重新采集。

评审现场最容易被问倒的几处

• 答不出「同一个人脸素材被反复上传怎么处理」，说明授权校验只做了入口，没做累积。
• 答不出「输出被二次编辑后标识还在不在」，说明标识方案只覆盖了原始产物。
• 答不出「日志里能查到谁生成的」，说明留档做了但没做主体绑定，等于没留。
• 答不出「换了底座模型后旧测试还作数吗」，说明没有版本绑定和复评触发规则。
• 答不出「第三方调用方出事谁负责」，说明调用链说明里缺了责任切分那一栏。

这几处有个共同点：都不是技术做不到，而是评估表里没写。如果平时把这四条对应的证据准备好，现场就不至于卡住。

一份评估表的填写顺序

建议按这个顺序填：场景界定、输入输出管控、可追溯性、权限与滥用、合规映射、遗留风险与责任人。每一栏留四列——当前状态、待补项、负责人、预计关闭时间。评审时只争论待补项，不重复确认已完成项，效率差很多。

• 对外版和内部版分开：对外版隐去内部接口细节，但待补项和责任人不能省。
• 文档头部写清版本号、评估日期、对应引擎版本，避免半年后对不上。
• 遗留风险栏必须写，写「无」反而显得没认真评。
• 评审结束后把待补项单独拉一张跟进表，按预计关闭时间盯，不要混在正文里。