写合规材料时最容易卡住的一步，是把「AI 安全」和「可信 AI」当成同一件事写进同一段。结果要么把技术风险写进了治理章节，要么把伦理原则塞进了安全测试项，评审一眼就看出概念混着用。这篇给你一条分辨思路：两个词各管什么、在哪重叠、什么情况下不适用，以及一份可以直接照着改文档的对照清单。
写合规材料时最容易卡住的一步，是把「AI 安全」和「可信 AI」当成同一件事写进同一段。结果要么把技术风险写进了治理章节，要么把伦理原则塞进了安全测试项，评审一眼就看出概念混着用。下面这条思路不追求学理严谨，只解决一件事：让你手里的文档能被人看懂、能被追问、能被验证。
先记住一个大方向：安全回答「会不会出事」，可信回答「能不能放心用」。前者偏工程与对抗，后者偏制度与责任。两者不是并列关系，也不是包含关系，而是部分重叠的两张网。分不清的时候，问自己一句：这条要求是靠一次测试证明，还是靠长期记录证明。
先把两个词各自的「管辖范围」划出来
AI 安全偏向「不出事」：模型与系统在对抗、误用、失控场景下的失效边界，关注注入、越权、泄露、跑飞这类可观测的技术风险。它的问题形式通常是「攻击者能不能做到 X」「极端输入下会不会 Y」，答案可以通过构造用例得到，也可以用探针反复回归。
可信 AI 偏向「可以被信任地使用」：在安全底线之上还叠加了公平、可解释、可追溯、责任归属、隐私与人的监督等治理属性。它的问题形式通常是「出了事谁负责」「这个决定能不能向外部解释」「更新之后谁来复核」，答案不在代码里，在流程和记录里。判断口诀：能被一次测试或一次攻击验证的，多归安全；要靠制度、流程、文档长期维持的，多归可信。
| 维度 | AI 安全 | 可信 AI |
|---|---|---|
| 核心问题 | 会不会被攻破、会不会失控 | 能不能被解释、被追责、被监督 |
| 典型证据 | 测试用例、探针结果、攻击复现 | 评审记录、责任矩阵、留证日志 |
| 失败形态 | 越权、泄露、注入生效 | 说不清、追不到、没人负责 |
| 维护方式 | 随模型和接口变化反复回归 | 随组织与法规变化定期复核 |
| 主要读者 | 工程与安全团队 | 合规、法务、管理层 |
- 不适用情形：只做内网小工具、不接触外部输入也不对外提供服务的场景，可信 AI 那一整套治理动作可以明显减配，但数据边界和留证仍要保留
- 边界模糊时先归档再讨论：把有争议的要求写进两栏表格，标上「靠测试」还是「靠记录」，多数争议会自己消失
- 不要用「安全」给治理问题兜底：把责任归属写进安全章节，评审会问你要测试报告，你拿不出来
- 也不要用「可信」给技术漏洞免责：公平性再好，注入照样能生效，两件事不能互相抵消
两个概念的交集在哪，别重复做两遍工
数据边界是共同核心：数据发到哪里、谁能看、留多久，既是安全项也是可信项。写文档时只写一次、双向引用即可，安全章节讲传输与存储控制，治理章节讲授权范围与保留期限，指向同一条原始要求，避免出现两个版本互相打架。
权限与最小可用同样重叠：技术上属于安全控制，治理上属于「谁负责」。同一条规则在安全章节描述成「默认拒绝、按需授权」，在治理章节描述成「授权人是谁、多久复核一次」，角度不同但底层是同一份权限清单，最好用同一个编号串起来。
可追溯性是最典型的交集。日志与留证既是事后排查的安全手段，也是可信 AI 里「可解释、可追责」的证据基础。提示词注入与越权工具调用则是另一处重叠区：它既是攻击面，也牵涉人的监督缺位。遇到这类词，建议到 安全与合规术语对照（/ai-dict/category/safety） 对齐措辞，省得同一件事在文档里长出三个名字。
| 重叠项 | 安全侧写法 | 可信侧写法 |
|---|---|---|
| 数据边界 | 传输加密、访问控制、留存上限 | 授权范围、告知同意、保留期限 |
| 权限管理 | 默认拒绝、最小权限、越权拦截 | 责任人、审批链、定期复核 |
| 可追溯 | 日志完整性、防篡改、可回放 | 决策解释、责任归属、留证年限 |
| 外部输入 | 注入检测、内容过滤、工具白名单 | 人工复核、异常上报、兜底预案 |
重叠项的处理顺序
- 先合并同类项把安全章节和治理章节里描述同一件事的句子并排贴出来，能合并的合并，不能合并的标明各自侧重
- 再统一编号给每条重叠要求一个统一编号，两个章节都引用它，评审时一搜就知道全貌
- 最后分配验证人每条要求指定一个验证角色：能测的由安全团队出报告，只能审的由合规出评审记录
合规读者能直接上手的三件事
第一件，拿现有制度文档做一次「归位」：每条要求后面标注它属于安全、可信、还是两者。标注不清的，说明它本来就没写清楚，这类条目通常最先在评审时被追问，优先处理。
第二件，给每条要求配一个验证方式。能测的归安全（探针、对照测试、攻击复现），只能审的归可信（评审记录、责任矩阵、更新机制）。配不出验证方式的要求，要么删掉，要么改写，不要留在文档里当摆设。
- 对不齐的口径统一到站内术语页，避免同一件事在安全章节和治理章节里用两个名字，可到 安全与合规（/safety） 分区对照
- 给每条重叠要求写一行「安全侧看什么、可信侧看什么」，让两个团队的读者各取所需
- 把验证方式直接写进要求后面，评审时不必再翻附件，省一轮来回
- 留有争议的条目单独列一张待定表，注明争议点和下次评审时间，不要假装已经解决
一份可以直接照着改的对照清单
把下面这张清单贴在文档首页，逐条打勾。打不了勾的条目就是下一轮要补的活，而不是需要再讨论的概念问题。需要看当时的模型资料和价格区间时，到 模型资料库（/models） 核对当时的数字，不要凭记忆写进材料。
| 检查项 | 属于 | 验证方式 |
|---|---|---|
| 外部输入有没有过滤与拦截 | 安全 | 探针与对抗用例 |
| 工具调用有没有白名单 | 安全 | 越权测试记录 |
| 数据留存有没有上限 | 两者 | 配置截图与授权书 |
| 决策能不能被解释 | 可信 | 解释模板与样例 |
| 出问题谁负责 | 可信 | 责任矩阵签字 |
| 更新后谁复核 | 可信 | 复核记录与周期 |
这套分法什么时候会失灵
面对强监管行业时，监管文件往往自带分类口径，应以监管口径为准，本文思路只用于内部沟通和自查，不要拿它去对抗检查表。硬把监管条目塞进安全或可信，反而会让材料更难被受理。
当团队只有一个人兼安全与合规时，两套动作的边界会自然糊掉，此时优先保证数据边界与留证这两件共同项，其余条目允许暂时合并描述，但要在文档里注明「待补」，别让评审以为你已经做完了。
采购第三方服务时，两个概念的举证责任不同：安全要多问检测口径与复测频率，可信要多问授权范围与责任条款，别用同一张问卷打发。评估中转服务时，检测口径和授权方式往往分开呈现，可先到 中转站目录（/sites） 看它的资质与说明，再决定要不要进入下一步。
下一步把这篇的对照清单复制进你正在写的材料，先跑一遍归位，再去站内核对当时的术语与数字，能省掉一轮返工。→常见问题
AI 安全和可信 AI 是不是一回事，只是叫法不同？
不是。安全更关注系统在攻击、误用、失效时会不会出事，大多能用测试和探针验证；可信 AI 是安全底线之上再加公平、可解释、可追溯、责任归属这些治理属性，靠制度和流程长期维持。两者有重叠但不互相包含。
写合规文档时，两个词应该分开写还是合并写？
建议先分开列，再标出重叠项。分开写能让评审看清哪些是技术验证、哪些是制度安排；重叠项比如数据边界、权限、留证，只写一次然后互相引用，避免同一件事在两章里出现两个说法。
如果公司规模很小，可信 AI 那套治理动作能省吗？
可以参考但不建议全砍。小团队至少要保留数据边界、最小权限和留证三件，因为它们同时是安全和可信的公共项，出事时也没有第二个人替你兜。公平、可解释这类偏治理的内容，可以按是否对外提供服务来决定做到什么程度。
