先定性：它是风险不是罪名
监管文件里很少出现「提示词注入」这个词，它通常被归入系统安全、数据泄露或内容安全事件。企业要做的是把它纳入既有的事件分类与应急预案，而不是另起一套制度，否则两套流程会互相打架。
映射到安全义务
网络运行安全与等级保护要求系统具备访问控制、日志审计与入侵防范能力，注入导致的越权调用与异常外联正落在这些条款下。等保测评时，日志与权限往往是必查项，也是这类项目最容易丢分的地方。
映射到数据义务
注入常被用来把上下文或知识库内容外带，若涉及个人信息或商业秘密，就构成数据安全事件，需要评估影响、采取措施并按规定报告。能不能说清泄露范围，取决于日志是否完整，事后再补是补不出来的。
映射到内容义务
被注入后的输出可能生成违规内容或错误信息，面向公众的服务要承担内容安全责任，并按要求做生成内容标识。护栏、投诉渠道与处置时限要写进制度，而不是等出事时临时找人拍板，那样既慢也无据。
边界：责任不能外推
把问题全部归给模型供应商通常站不住，服务提供者对自己场景的输出与数据流负有责任。合同可以分配责任，但不能免除法定义务，这一点在采购谈判和技术评审时都要提前讲清楚，避免事后扯皮。
适用与不适用
适合谁
- 面向公众提供生成式 AI 服务的企业，需承担内容责任
- 使用 Agent 处理内部流程的公司，工具权限较宽
- 需要把 AI 风险写进合规台账的法务与安全团队
不适合谁
- 仅做离线实验、不接触真实数据与用户的项目
- 希望靠一份声明转移全部责任的团队
典型场景
某银行上线智能客服后，安全团队在演练中用一份带隐藏指令的 PDF 诱导助手读取内部知识库片段并输出到对话框。事件被定性为数据安全事件，合规部门据此补充日志字段、对外发域名做白名单，并把注入纳入季度演练科目。
可执行步骤
- 把注入可能导致的越权、泄露、错误输出与供应链影响写进事件分级，留出复核时间。
- 对照等级保护要求核查日志、访问控制与外联管控是否覆盖 AI 链路，形成书面结论。
- 为可能涉及个人信息外带的场景准备影响评估模板与报告路径，由业务方签字。
- 把生成内容标识、投诉受理与处置时限写进对外服务流程，在工单里关闭。
- 在采购合同里写清供应商与自身的安全责任分界和配合义务，记录处理经过。
常见坑
- 把注入当成纯技术缺陷，不进事件台账，既无法统计规模，也提不出改进要求，跨部门协调成本很高。
- 演练只测聊天框，不测文档、邮件与工具返回值，真实入口基本没有被覆盖到，事后举证会非常困难。
- 日志只记请求不记工具调用与检索结果，泄露范围说不清，影响评估也就无从下手，争议时各说各话。
- 合同把安全责任整体推给供应商，出了事仍要自己承担法定义务，还多出一层纠纷，最后还是自己整改。
自检与验收清单
- 注入是否已纳入既有安全事件分级与应急预案
- 日志是否覆盖检索结果、工具调用与最终输出，可追溯
- 是否准备了个人信息外带情形的影响评估模板
- 生成内容标识与投诉受理渠道是否已经落地，且用户可见
- 采购合同是否写清双方安全责任与配合义务，留档备查
常见问题
开源模型自己部署也要担内容责任吗？
面向公众提供服务时，部署方式不改变服务提供者的责任。内容安全、标识与投诉处置仍要落实，具体适用哪套要求取决于服务形态与是否面向境内公众，备案范围也要一并确认。
注入导致泄露必须报告吗？
是否报告取决于数据类型、影响范围与适用规定，涉及个人信息或重要数据时通常需要评估并按程序处理。建议先固定证据、评估影响，再由法务判断报告义务与时限，报告口径要与法务一致。
等保测评能覆盖 AI 风险吗？
能覆盖一部分，比如身份鉴别、访问控制与安全审计，但覆盖不了模型输出与提示词层面的风险。建议在等保基线之上补一套 AI 专项检查，两者不互相替代，专项检查要覆盖提示词与工具。