AI 安全是什么？从威胁建模到上线与事件响应的全生命周期指南

一句话回答：AI 安全不是给模型加一个“敏感词开关”，而是对数据、模型、提示、检索、工具、身份、输出和运行环境建立贯穿设计、开发、测试、上线、运营与退役的控制闭环。真正可上线的 AI 系统必须能回答四个问题：保护什么、谁能做什么、失败时如何发现、出事后如何停止和恢复。

本文面向准备采购、开发或部署生成式 AI、RAG 与智能体的产品、研发、安全和业务团队。它不把“安全”缩减为越狱测试，也不把一次红队结果当成永久保证；重点是给出可以进入需求文档、测试计划、上线审批和事故复盘的检查方法。资料复核日期为 2026 年 7 月 18 日。

先分清：AI 安全到底保护什么

AI safety 常关注系统是否造成意外伤害、歧视、误导或失控；AI security 更关注攻击者如何窃取、操纵、越权或破坏系统。真实产品同时面对两类问题。例如，模型编造医疗建议可能是可靠性与安全风险；攻击者把恶意指令藏进检索文档，诱使智能体外发客户数据，则同时涉及提示注入、访问控制和数据泄露。

NIST AI 风险管理框架使用 Govern、Map、Measure、Manage 组织风险工作；其AI Resource Center目前明确提示 AI RMF 1.0 正在修订。面向生成式 AI 的风险与建议行动可核对NIST AI 600-1 Generative AI Profile。因此团队应记录采用的框架版本与复核日期，不应把任何清单写成永不过期的合规证明。

第一步：先画系统边界，再谈模型风险

用户看到的是一个聊天框，攻击面却可能包括登录、API 网关、文件上传、向量库、对象存储、第三方模型、浏览器、插件、工具执行器、人工审批和日志平台。只测最终回答，会漏掉身份、供应链和传统 Web 安全问题。先建立资产与数据流图，并明确哪些组件由自己控制、供应商控制或共同负责。

第二步：用威胁场景取代抽象的“注意安全”

威胁模型要写成可测试的路径：攻击者是谁，通过什么入口，操纵哪项资产，系统为什么会接受，造成什么影响，现有控制如何阻断。MITRE ATLAS是持续更新的 AI 对抗战术、技术和案例知识库；OWASP Top 10 for LLM Applications 2025则适合检查提示注入、敏感信息泄露、供应链、数据与模型污染、输出处理、过度授权等应用风险。二者是建模输入，不是勾选完即可“认证安全”的标准。

如果团队需要专门设计攻击样本，可继续参考站内的AI 红队测试方法；若主要问题是虚假陈述与引用失真，应把回答拆成可逐条核对的原子主张，并分别检查来源忠实度、完整性、充分性与潜在影响。红队负责主动寻找失败，不替代日常权限控制、监控和恢复机制。

第三步：把安全要求分配到六个生命周期门禁

CISA 对联合指南的说明及英国 NCSC 的 Guidelines for Secure AI System Development覆盖安全设计、开发、部署和运营，并强调 Secure by Design。落实时应让每一阶段产生可审计交付物，而不是上线前临时让安全团队“测一下”。

第四步：数据、模型和供应商要分别验收

“供应商说不会训练”不能替代合同、配置和删除验证。对外部模型 API，至少确认数据用途、存储区域、保留时间、子处理者、管理员权限、训练退出、删除机制、事故通知、版本变更和退出导出。对开源模型，还要核对来源、许可证、权重哈希、模型卡、依赖与推理镜像。

更完整的个人信息、训练数据和合规边界可结合站内的AI 数据合规指南；版权、训练材料和生成内容归属问题见AI 版权核验清单。

第五步：RAG 与智能体必须分开设防

RAG 的核心风险是检索到不该看的、被污染的或已经过期的内容；智能体又增加了“把错误判断变成真实动作”的风险。检索质量高不等于权限正确，模型拒答也不能代替服务端鉴权。

知识库的权限与来源设计见企业 AI 知识库教程；工具调用的参数、服务端授权和生产验收见Function Calling 与 Tool Use 指南。两篇文章分别解决“能读什么”和“能做什么”，不要混成一个模型提示词。

第六步：测试计划必须覆盖正常、失败、攻击和恢复

只展示几个成功对话是演示，不是验收。测试集应版本化，记录输入、预期、模型与知识版本、配置、实际结果、判定人和复现步骤。模型输出有随机性时，可重复运行并报告通过率与最坏失败，不要只保留最好的一次。

内容审核只是其中一层。审核系统本身仍需版本化回归、误拦与漏放分析，实施方式见AI 内容审核工程指南。模型滥用、深度伪造、欺诈与自动化攻击的组织级风险，可结合AI 滥用风险与防范框架建立升级路径。

第七步之前：把“看起来安全”变成可量化验收

AI 安全指标不能只统计拦截次数。拦得越多可能意味着攻击增多，也可能意味着规则误伤正常用户；平均通过率也可能掩盖某个租户、语言或高风险动作的严重失败。指标必须同时说明分母、样本来源、版本、影响等级和人工判定方法，并将硬门禁与趋势指标分开。

对存在随机性的模型，单个样本运行一次只能说明那次结果。高风险测试应固定环境并重复执行，记录模型版本、温度、系统提示、知识版本和工具配置；如果供应商使用不可见的滚动更新，则应增加基准样本监控，以行为变化触发复测。指标阈值也不能从网上抄一个统一数字，而应由影响、可逆性、人工复核能力和组织风险容忍度共同决定。

残余风险必须有人签收，不能藏在报告附件里

测试结束后仍可能存在无法完全消除的风险，例如低概率幻觉、供应商不可见更新或少量误拒。团队应为每项残余风险记录失败场景、影响对象、当前控制、监控信号、临时限制、责任人、复核日期和接受者。技术人员可以说明证据，但不能替业务所有者替代决定可接受的损失。

模型、提示或供应商变化时，不能默认安全结论继续有效

生成式 AI 产品常在没有传统版本发布仪式的情况下变化：供应商可能更新底层模型，团队可能调整系统提示、检索切分、嵌入模型、审核策略或工具 schema。每一项变化都可能改变拒答、引用、权限和动作行为。变更管理应先判断影响面，再决定执行完整回归还是针对性复测。

如果供应商不提供精确模型版本，团队至少要保留一组稳定基准请求，持续观察输出结构、拒答、引用、延迟、费用和工具选择的变化。检测到明显漂移时，先冻结扩大使用范围，再决定是否回退、切换模型或接受新的残余风险。所谓“自动升级到更强模型”不是安全理由，因为能力提高也可能扩大可执行范围和攻击收益。

第七步：上线门禁要能直接作出“放行或停止”决定

不要用一个总分掩盖致命缺陷。跨租户泄露、未授权付款、不可逆删除和密钥暴露应设为硬门禁，即使平均回答质量很高也不能抵消。低风险内部摘要工具与可操作生产系统的门槛也不应相同，应按影响范围和可逆性分级。

第八步：日志要支持调查，但不能成为新的数据仓库

日志字段、访问者、保存期限和删除机制应在上线前确定。为调试临时打开完整提示记录时，应限定范围、脱敏、审批并设置自动到期；不能把“以后可能有用”作为永久收集理由。

第九步：事件响应要围绕 AI 特有证据设计

中国团队还要核对哪些现行要求

安全工程与法律适用范围不能互相替代。面向中国境内公众提供生成文本、图片、音频或视频服务时，应核对《生成式人工智能服务管理暂行办法》。国家标准信息平台显示，GB/T 45654—2025《网络安全技术 生成式人工智能服务安全基本要求》已于 2025 年 11 月 1 日实施，范围包括语料安全、模型安全、安全措施与评估要求。做组织级风险梳理时，还可参照全国网络安全标准化技术委员会发布的《人工智能安全治理框架》理解风险分类与治理思路。

生成合成内容还应核对《人工智能生成合成内容标识办法》及配套标准。普通企业内部使用、面向公众提供服务、受监管行业和高风险自动决策的适用义务不同；本文提供工程核验框架，不替代针对具体业务、地区和行业的法律意见。

小团队的最小可行安全清单

资源有限不等于省略控制。小团队可以先把最危险的权限与数据问题做对，再逐步扩展测试覆盖：

常见问题

通过内容审核，是否就代表 AI 系统安全？

不代表。内容审核主要处理输入或输出类别；跨租户访问、提示注入、工具越权、密钥泄露、供应链污染和不可逆动作仍需要独立控制与测试。

使用知名大模型，应用层还需要做安全测试吗？

需要。供应商负责其服务边界，你仍负责身份、数据、检索、提示、插件、工具、业务规则和用户告知。更换模型也可能改变拒答、工具调用和输出格式，应触发回归。

系统提示词能阻止提示注入吗？

不能把它当作唯一边界。提示可以降低部分失败，但真正的保护来自来源限制、内容与指令分离、服务端鉴权、最小权限、参数校验、人工审批、监控和回滚。

多久应重新评估一次？

固定周期只是下限。模型、知识库、提示模板、工具、权限、供应商条款或高风险失败发生变化时，都应立即触发相应范围的重新测试；重大事件后还要把失败样本加入回归集。

结论：安全不是“模型会不会拒答”，而是系统能否受控失败

判断 AI 系统是否具备上线条件，不要只问模型回答得多聪明。应检查资产和数据流是否清楚、权限是否在服务端执行、测试是否覆盖攻击与恢复、真实动作是否可预览和撤销、日志是否足以复现、事件发生时是否能迅速限制影响。能发现、停止、解释、恢复并持续改进，才是全生命周期 AI 安全的核心。

编辑复核与纠错记录：本文由兰塞 AI 编辑流程于 2026 年 7 月 18 日重构。旧稿将 AI 安全泛化为“数字免疫系统”，缺少可验证来源、内链和运行门禁，并使用来源不明的百度图片；本次删除无法核验的抽象断言，依据 NIST、OWASP、MITRE、CISA/NCSC、中国网信办和国家标准信息平台的一手资料，重建为系统边界、威胁场景、六阶段门禁、RAG 与智能体控制、测试、上线、日志和事件响应框架。本站的来源、更新与纠错原则见关于本站与编辑规范。