How to Review LLM Applications for Security and Compliance

大模型应用的安全合规审查，不是上线前补一份隐私政策。 它要回答四个核心问题：产品由谁提供、数据从哪里来并流向哪里、模型能生成或执行什么、发生风险时谁能发现并处置。审查结论应落实为产品限制、技术控制、运营流程和可留存的证据。

本文面向在中国境内研发或运营大模型应用的产品、技术、安全、法务和业务团队，适用于 AI 问答、企业知识库、智能客服、内容生成、数字人、Agent 和接入第三方模型 API 的业务系统。校对日期为 2026 年 8 月 21 日。

本文提供一般性的项目审查方法，不构成法律意见。金融、医疗、教育、新闻出版、网络视听、汽车、政务等行业，以及处理重要数据、国家秘密或大量敏感个人信息的项目，应由法务、安全和对应行业专家进行专项审查。

---

一、先确定审查边界：不是所有 AI 项目适用同一套手续

审查的第一步不是列法规，而是画清产品边界。至少确认以下事实：

1. 服务对象是企业内部员工、特定客户，还是中国境内不特定公众；
2. 应用只调用第三方已备案模型，还是自行训练、微调或提供模型能力；
3. 输出仅供内部辅助，还是会直接展示、发布或用于业务决策；
4. 是否允许用户输入、上传文件，或者把生成内容分享给他人；
5. 是否处理个人信息、敏感个人信息、商业秘密、重要数据或国家秘密；
6. 模型、日志、向量库、监控或人工审核服务是否位于境外；
7. AI 只生成建议，还是可以调用工具执行付款、发信、删改数据、创建订单等操作。

《生成式人工智能服务管理暂行办法》主要适用于向中国境内公众提供生成文本、图片、音频、视频等内容的服务；企业、科研机构等研发或应用生成式人工智能技术但未向境内公众提供服务的，不适用该办法。这个区别会影响生成式人工智能服务备案、安全评估等判断，但不意味着内部应用不受监管。内部应用仍需遵守网络安全、数据安全、个人信息保护、保密、知识产权和行业监管要求。

因此，审查报告首页应明确写出“适用场景”和“不适用场景”，并记录判断依据。不能只用“内部工具”“智能助手”这样的产品名称代替事实分析。

---

二、建立一张完整的数据与能力地图

安全合规审查要以真实的数据流和调用链为依据。建议将一次完整请求拆成以下环节：

• 用户注册、登录与身份信息；
• 用户输入的提示词、图片、语音和附件；
• 前置内容审核、脱敏和分类；
• 知识库检索、向量化、重排与权限过滤；
• 向模型供应商发送的具体字段；
• 模型生成的文本、图片、音视频或结构化结果；
• 后置审核、事实校验与风险拦截；
• Agent 调用的工具、接口、数据库和第三方系统；
• 对话历史、反馈、审计日志、监控告警和人工复核；
• 数据保存、备份、导出、删除及跨境传输。

地图中每个节点至少标注：数据类别、处理目的、处理主体、存储地点、保存期限、访问角色、传输对象和安全措施。不能只写“数据已加密”，还要说明在传输、存储、日志、备份和密钥管理的哪个环节使用了什么控制。

如果团队无法回答“用户上传的文件会不会进入模型厂商日志”“停用账号后向量库中的内容如何删除”“运维人员能否看到完整对话”，说明产品还不具备通过审查的基础。

---

三、七个审查面分别查什么

1. 主体、资质、备案与安全评估

先明确应用运营者、模型提供者、云服务商和实际数据处理者，不要让官网主体、应用商店主体、合同主体和隐私政策主体互相矛盾。

向境内公众提供具有舆论属性或者社会动员能力的生成式人工智能服务，应根据《生成式人工智能服务管理暂行办法》及算法、深度合成相关规定判断安全评估和算法备案义务。采用已经备案的生成式人工智能服务开发应用或功能的，还应结合属地网信部门要求判断应用登记，并在显著位置或产品详情页公示所使用模型的名称和备案号。国家网信办会持续发布生成式人工智能服务已备案和已登记信息，选型和上线前都应核验，不应只接受供应商口头承诺。

审查时至少留存：

• 运营主体与服务范围说明；
• 模型名称、版本、供应商和备案或登记信息；
• 自研、微调、第三方 API 调用之间的关系；
• 是否具有舆论属性或者社会动员能力的论证；
• 应办理的备案、登记、安全评估、许可和应用商店材料；
• 备案信息变更、模型切换和产品重大升级时的复审机制。

备案不是“一次办完永久有效”。模型、算法、服务形式、应用领域或运营主体发生实质变化时，应重新判断变更手续和审查范围。

2. 数据来源、训练语料与知识产权

自研或微调模型时，应形成训练数据台账，证明数据来源合法、用途与授权范围匹配，并能处理权利人的投诉和删除请求。采购数据、开源数据、公开网页和用户贡献内容不能简单等同于“可以训练”。

重点检查：

• 数据是自有、采购、授权、开源还是公开抓取；
• 许可条款是否允许训练、微调、商用和生成内容；
• 是否含个人信息、敏感个人信息、商业秘密或受保护作品；
• 是否完成清洗、去重、质量评估、偏差检测和有害内容过滤；
• 是否能定位数据批次、版本、来源和处理记录；
• 权利人投诉、下架、删除后，训练集、向量库和缓存如何联动处理。

只调用第三方模型也要审查用户输入和知识库数据。企业资料进入提示词、向量库或第三方插件后，仍然属于数据处理活动，不能因为“没有用于训练”就跳过授权、保密和安全评估。

3. 个人信息、敏感数据与数据出境

个人信息审查应围绕合法性基础、最小必要、透明告知、保存期限、个人权利和安全措施展开。应逐项确认哪些字段真正为 AI 功能所必需，默认不把身份证号、联系方式、医疗记录、金融账户、生物识别、精确位置等敏感信息发送给模型。

在处理敏感个人信息、利用个人信息进行自动化决策、委托处理、向其他处理者提供、公开个人信息或向境外提供个人信息等法定情形下，应事前开展个人信息保护影响评估，并依法保存评估报告和处理记录。可依据《中华人民共和国个人信息保护法》和《个人信息保护合规审计管理办法》建立评估与定期审计机制。

审查不能只看模型服务器位置。以下环节都可能形成数据出境：

• 调用境外模型、Embedding、内容审核或语音识别 API；
• 境外日志、监控、客服、工单或分析平台接收提示词和标识符；
• 境外团队远程访问境内数据库或对话记录；
• 海外云备份、容灾或全球 CDN 携带业务数据。

存在出境时，应根据《促进和规范数据跨境流动规定》判断是否适用豁免、安全评估、个人信息出境标准合同或个人信息保护认证，并履行告知、单独同意、影响评估等相应义务。不要脱离关键信息基础设施运营者身份、重要数据认定、个人信息数量和敏感程度直接套用一个结论。

国家秘密、工作秘密和明确禁止输入外部模型的内部资料，应通过数据分级、上传限制、终端防泄漏和员工培训形成硬边界，不能只在用户协议中写一句“请勿上传敏感信息”。

4. 内容安全、生成标识与用户治理

内容安全需要同时覆盖输入和输出，并考虑多轮对话、角色扮演、编码变体、图片文字混合、工具返回内容和知识库投毒等绕过方式。

面向公众的生成或深度合成服务通常应具备：

• 真实身份信息认证及账号管理；
• 违法和不良信息规则、特征库及动态更新；
• 输入、检索结果、模型输出和发布环节的分层审核；
• 高风险请求拒答、降级、人工接管和应急停服；
• 投诉、举报、申诉、辟谣和违规用户处置；
• 网络日志、处置记录和重大事件报告机制；
• 防止提示词注入、越权检索、数据投毒和审核绕过的专项测试。

《人工智能生成合成内容标识办法》自 2025 年 9 月 1 日起施行，对文本、图片、音频、视频和虚拟场景规定了显式标识与文件元数据中的隐式标识要求。应用提供下载、复制、导出或对外发布能力时，要验证标识在完整链路中不会丢失；用户申请不含显式标识的内容时，还涉及协议说明、使用责任和不少于六个月的相关日志留存要求。

如果应用是内容传播平台，还应识别用户上传内容中的隐式标识、用户声明或疑似生成痕迹，并按规定增加相应提示。产品评审应包含实际截图、导出文件元数据和传播链路测试，不能只提交一张设计稿。

5. 模型、供应商与第三方组件

接入成熟模型不等于把责任全部转给供应商。应用运营者仍要判断自己的处理目的、用户告知、内容治理、权限控制和行业义务。

供应商审查建议覆盖：

• 服务主体、模型备案登记、等保和安全认证情况；
• 输入输出是否用于训练，默认设置能否关闭；
• 数据存储地域、子处理者、跨境路径和远程访问；
• 日志内容、保存期限、删除机制和账号终止后的处理；
• 加密、密钥、租户隔离、漏洞响应和事件通知时限；
• 可用性、限流、模型版本升级、接口停用和退出迁移方案；
• 合同中的保密、数据处理、安全事件、知识产权、审计与责任条款。

模型或供应商更换应触发变更评审。尤其要检查新模型是否改变数据出境、训练使用、标识实现、备案公示、内容过滤和结果质量，不能把它当成普通依赖版本升级。

6. 权限、安全工程与 Agent 行为

传统应用主要控制“谁能读写什么”，Agent 还要控制“模型能代表谁执行什么”。所有外部工具调用都应按不可信输入设计。

最低控制建议包括：

• 知识库检索沿用源系统权限，检索前做身份和授权过滤；
• 模型只获得完成当前任务所需的最小工具与最小字段；
• 查询与写入、低风险与高风险工具分离授权；
• 付款、发信、发布、删除、修改权限等高风险动作必须二次确认或人工审批；
• 工具参数在服务端校验，不直接执行模型生成的命令、SQL 或 URL；
• 防止提示词泄露、越权调用、跨租户访问、SSRF、恶意文件和依赖投毒；
• 对关键操作保留用户、模型、工具、参数、审批和结果的完整审计链；
• 提供额度、频率、金额、数据量和影响范围限制，以及一键停用开关。

上线前至少进行提示词注入、越权访问、敏感信息泄露、有害内容、模型幻觉、工具滥用和资源耗尽测试。测试集应包含业务真实风险，并保留模型版本、参数、结果和整改记录，避免只展示几个“正常问题都能回答”的演示案例。

7. 用户权益、人工复核与行业专项要求

应用应明确告诉用户正在与 AI 交互、AI 能力与限制、个人信息如何处理、内容如何标识、如何投诉以及何时由人工接管。涉及自动化决策时，应评估透明度、公平性和对个人权益的影响，不得实施不合理的差别待遇，并在适用时提供说明、拒绝或人工复核渠道。

以下场景通常需要更严格的专项评审：

• 医疗诊断、治疗建议、健康风险预测；
• 授信、保险、证券、支付和反欺诈决策；
• 招聘筛选、绩效、解聘等影响劳动者权益的决策；
• 面向未成年人的陪伴、教育、内容或消费服务；
• 新闻采编发布、网络出版、网络视听和文化内容；
• 人脸、人声克隆、数字人和高度拟真的合成场景；
• 公共服务、司法、政务及影响大量人群权益的系统；
• 具有自主规划和外部执行能力的高权限 Agent。

从事人工智能科研和技术开发且涉及科技伦理敏感领域的单位，还应结合《科技伦理审查办法（试行）》及适用的最新专项规则判断科技伦理审查要求。伦理审查不能替代数据、内容、网络和行业合规审查。

---

四、把审查做成可执行的上线闸门

建议把问题分为红线、条件通过和优化三类。

红线：未解决不得上线

• 运营主体、服务对象或主要数据流仍不清楚；
• 应办理的备案、登记、许可或安全评估没有完成；
• 违法取得的数据、无权使用的语料或国家秘密进入系统；
• 高风险 Agent 可以未经确认直接执行不可逆操作；
• 存在跨租户访问、严重越权或敏感信息直接泄露；
• 公众服务缺少必要的内容审核、生成标识或应急停服能力；
• 医疗、金融等高风险结论直接替代专业人员作出最终决定。

条件通过：明确责任人和完成期限

• 个别低风险文案、告知或协议需要调整；
• 监控阈值、投诉 SLA 或抽检比例需要在试运行中校准；
• 非核心供应商材料待补充，但已有替代控制且不影响法定义务；
• 低风险场景的测试覆盖率需要继续扩充。

每个条件项都要写明负责人、截止日期、验证方式和逾期处置。不能以“后续优化”代替结论。

优化项：进入版本计划持续跟踪

例如更细的可解释界面、更自动化的红队测试、更完善的数据血缘、更便捷的用户权利入口。优化项也应进入产品待办，而不是留在会议纪要里自然消失。

---

五、上线前应形成哪些证据

一次可追溯的审查，至少应留下以下材料：

1. 产品说明、服务对象、业务流程和功能清单；
2. 系统架构图、数据流图、数据分类分级清单和出境判断；
3. 模型、算法、数据集、知识库、插件和供应商台账；
4. 备案、登记、安全评估、等保、许可或行业审批材料；
5. 隐私政策、用户协议、AI 提示、生成标识和投诉申诉页面；
6. 个人信息保护影响评估、供应商评估和科技伦理审查记录；
7. 安全测试、内容安全测试、红队测试和整改复测报告；
8. 权限矩阵、人工审批点、日志策略和应急预案；
9. 上线评审结论、遗留风险、接受风险的批准人和复审日期；
10. 模型升级、业务扩展、数据源变化和监管更新的变更触发规则。

《网络数据安全管理条例》要求网络数据处理者建立相应的数据安全管理与保护机制。审查材料不应只是为“过会”制作，而要能够支持日常运营、事件处置、监管检查和后续审计。

---

六、上线后仍要持续审查

大模型的输出会随模型版本、提示词、知识库、用户行为和外部工具变化。一次上线评审不能覆盖整个生命周期。

以下变化应触发重新审查：

• 从内部使用扩展到公众服务；
• 新增图片、语音、视频、数字人或内容发布能力；
• 更换模型、供应商、部署地域或内容审核服务；
• 新增个人信息、敏感数据、重要数据或境外处理；
• 新增知识库、联网搜索、第三方插件或高权限工具；
• 从“只给建议”升级为自动执行决策或业务操作；
• 用户规模、行业场景或风险等级显著变化；
• 发生安全事件、重大投诉、越狱绕过或监管规则调整。

运营期间应持续做输出抽检、风险指标监控、滥用分析、漏洞修复、规则更新和应急演练。对同一高风险问题反复出现的，不应只补关键词，而要追溯数据、模型、提示词、权限、流程和人员责任的系统原因。

---

七、一页式审查清单

评审会可以按以下顺序逐项确认：

• 范围：服务谁，部署在哪里，AI 能生成什么、执行什么；
• 主体：运营者、模型方、云服务商和数据处理角色是否清楚；
• 手续：备案、登记、安全评估、许可、等保和行业审批是否适用并完成；
• 数据：来源是否合法，是否最小必要，是否含敏感、重要、保密或出境数据；
• 模型：备案版本、训练使用、存储地域、升级和退出机制是否明确；
• 内容：输入输出审核、AI 标识、投诉申诉、辟谣和应急停服是否可用；
• 权限：知识库是否按原权限检索，Agent 工具是否最小授权，高风险动作是否人工确认；
• 权益：是否充分告知，能否撤回、删除、申诉和获得人工复核；
• 测试：越权、泄露、注入、幻觉、有害内容和工具滥用是否经过复测；
• 证据：负责人、日志、评估报告、审批结论和复审触发条件是否留存。

真正有效的安全合规审查，最终应在产品里看得到、在代码和配置里查得到、在运营流程中执行得到、在日志和文档中证明得到。做到这四点，大模型应用才具备可上线、可运营、可审计和可持续迭代的基础。