本文为 M3AAWG（Messaging, Malware and Mobile Anti-Abuse Working Group）于 2025 年 5 月发布的 AI Model Lifecycle Security Best Common Practices 的中文译本。原文参考 URL：http://www.m3aawg.org/AIModelLifecycleSecurityBCP。本译本仅用于技术交流，不构成法律建议；具体合规事宜请咨询所在机构的法律顾问。
1. 范围
1.1. 引言与概述
AI 生命周期（AI lifecycle）指人工智能系统从开发、部署到维护的端到端过程。当前实践涵盖多个阶段，包括数据收集、预处理、模型开发、训练、评估、部署、监控和再训练。
每个阶段对于确保 AI 应用与服务的有效性、可靠性和安全性都至关重要。在整个 AI 生命周期中，必须遵循最佳实践以缓解风险、确保透明度并维护系统完整性。这包括对训练数据来源实施完整性和真实性控制、采用稳健的模型开发和部署流程，以及持续监控和更新 AI 系统以适配不断变化的环境和需求。
本文档不构成法律建议；请咨询所在机构的法律顾问。
1.2. 文档目的
本文档规定了截至发布之日已知的最佳通用实践，用于评估 AI 应用与服务（无论是采购还是内部开发）的安全性。其目标是确保从数据收集到部署和监控的 AI 生命周期各阶段均遵循最佳实践，以缓解风险、确保透明度并维护系统完整性。
通过实施稳健的模型开发和部署流程，并持续更新 AI 系统以适应变化的环境，本指南旨在提升 AI 应用与服务的有效性、可靠性和安全性。本文档旨在为信息技术领域的从业者提供具有明确规范性语言的特定最佳通用实践。
本文档意在补充其他相关机构（如 ISO/IEC、美国国家标准与技术研究院 NIST、欧洲电信标准化协会 ETSI、CEN/CENELEC 和 IEEE）的现有实践。它将根据技术演进进行更新，旨在支持实施者和从业者，而非规定强制要求。
1.3. 术语说明
依据 RFC 2119 并与 ISO/IEC 保持一致，本文档使用 MUST（必须）、MUST NOT（禁止）、SHOULD（应当）、SHOULD NOT（不应）等术语，含义符合标准 RFC 2119 定义。
2. 技术指导
使用 AI 的软件系统是多步骤、通常较为复杂的流程的结果，这些流程包括获取和准备数据、训练和测试模型、部署和运维 AI 系统，以及在必要时妥善退役这些系统所需的相关技术步骤。以下各小节针对 AI 生命周期的关键阶段提供编号化的最佳实践建议。
2.0.1. 训练数据 (Training Data, TD)
训练数据的完整性和真实性是模型安全的基础。以下建议针对训练数据的获取、标注、溯源和安全保护。
| 编号 | 建议 | 等级 |
|---|---|---|
| TD-001 | 所有训练数据源必须（MUST）在采集时计算 SHA-256 哈希值作为完整性校验基准，并将哈希值安全的元数据存储，用于后续的完整性验证。 | MUST |
| TD-002 | 从外部获取的训练数据集必须（MUST）附带数字签名，接收方应在使用前验证签名，确保数据来源的真实性和完整性。 | MUST |
| TD-003 | 训练数据的数字签名应（SHOULD）基于公钥基础设施（PKI, Public Key Infrastructure）证书链进行验证，以确保签名方的身份可信。 | SHOULD |
| TD-004 | 数据来源的透明性应当（SHOULD）记录在案，包括数据采集时间、采集方法、数据源组织/平台名称以及数据的使用许可条款。 | SHOULD |
| TD-005 | 训练流程的元数据——包括所用数据集版本、预处理脚本哈希、训练超参数配置——必须（MUST）被完整记录并签名存储，以确保可追溯性。 | MUST |
| TD-006 | 组织应（SHOULD）在数据收集阶段实施 PII（Personally Identifiable Information, 个人身份信息）检测与脱敏机制，避免未经授权的个人信息流入训练数据集。 | SHOULD |
| TD-007 | 数据标注过程应当（SHOULD）记录标注人员身份、标注工具版本、标注指南版本及标注时间戳，以支持标注质量的审计。 | SHOULD |
| TD-008 | 标注元数据和标签数据自身应（SHOULD）附带数字签名，确保标注结果在存储和传输过程中未被篡改。 | SHOULD |
| TD-009 | 训练数据集中使用的任何第三方知识产权（IP, Intellectual Property）内容必须（MUST）声明其来源和使用权限，包括许可证类型和适用范围。 | MUST |
| TD-010 | 训练数据中已知的偏差（bias）应当（SHOULD）在数据文档中明确列出，包括人口统计偏差、采样偏差和标注偏差等。 | SHOULD |
| TD-011 | 数据删除请求的处理流程必须（MUST）被记录并实施，确保训练数据集中被要求删除的数据条目能够在合理时间内被移除或隔离。 | MUST |
| TD-012 | 当使用第三方预训练模型进行微调时，应（SHOULD）记录原始模型的训练数据来源、训练方法和已知限制，并确认微调数据与原始训练数据在分布上不存在严重冲突。 | SHOULD |
2.0.2. 模型训练 (Model Training, MT)
模型训练阶段是对训练数据安全控制的延续，要求在训练执行时验证输入数据的完整性，并对产出的模型权重实施保护。
| 编号 | 建议 | 等级 |
|---|---|---|
| MT-001 | 训练启动时必须（MUST）重新验证所有输入训练数据集的 SHA-256 哈希值，确认与采集时记录的哈希值一致，防止训练管道中的数据被替换或篡改。 | MUST |
| MT-002 | 训练过程中使用的签名数据集应（SHOULD）在加载时执行签名验证，确认数字签名有效且签名者已被授权提供该数据。 | SHOULD |
| MT-003 | 数字签名的有效期和吊销状态必须（MUST）在训练时被检查，过期的证书或已被吊销的签名对应的数据不应（SHOULD NOT）用于训练。 | MUST/SHOULD NOT |
| MT-004 | 模型权重应当（SHOULD）根据安全敏感级别进行分类（如公开级、内部级、机密级），不同级别的权重采用相应的访问控制和存储保护措施。 | SHOULD |
| MT-005 | 每次训练产生的模型权重文件必须（MUST）附带完整性校验值（如 SHA-256），并在训练元数据中记录。 | MUST |
| MT-006 | 模型权重和关联元数据应（SHOULD）由训练系统自动签名，确保权重文件与训练配置、数据版本、代码版本的对应关系不可抵赖。 | SHOULD |
| MT-007 | 训练环境应当（SHOULD）与生产环境隔离，训练集群的网络访问应限制在最小必要范围内，实施网络分段。 | SHOULD |
| MT-008 | 训练代码的版本控制必须（MUST）使用 Git 等版本管理系统，每次训练运行对应的代码提交哈希应被记录在训练元数据中。 | MUST |
| MT-009 | 训练过程中使用的依赖库和运行时环境应（SHOULD）通过软件物料清单（SBOM, Software Bill of Materials）进行管理，确保依赖项的版本和来源可追溯。 | SHOULD |
2.0.3. 模型测试 (Model Testing, MTEST)
模型在部署前须经过充分的安全测试，以识别潜在漏洞和对抗性鲁棒性不足。
| 编号 | 建议 | 等级 |
|---|---|---|
| MTEST-001 | 模型在部署前必须（MUST）进行红队测试（red-team testing），由安全团队模拟攻击者尝试绕过模型的检测或决策逻辑，评估模型的对抗性鲁棒性。 | MUST |
| MTEST-002 | 测试环境应（SHOULD）在尽可能接近生产环境的条件下进行，包括使用与生产一致的推理框架版本、硬件加速器和 API 接口，避免环境差异导致的测试盲区。 | SHOULD |
| MTEST-003 | 对从第三方获取或经微调的模型，部署前应当（SHOULD）进行恶意软件扫描，确保模型文件中未植入隐藏的后门或恶意载荷。 | SHOULD |
2.0.4. 模型部署 (Model Deployment, MD)
模型部署环境的安全性是保障模型推理服务可信运行的前提。
| 编号 | 建议 | 等级 |
|---|---|---|
| MD-001 | 模型的部署过程必须（MUST）通过变更管理流程控制，部署操作应有审计记录，生产环境中的模型版本应与配置管理数据库保持一致。 | MUST |
Docker/容器安全： 模型推理容器应（SHOULD）使用最小化基础镜像，移除不必要的工具和库；容器镜像应通过签名验证并在私有镜像仓库中托管；运行时应当以非 root 用户运行推理进程。
基础设施安全： 推理服务器应（SHOULD）部署在隔离的网络段中，仅暴露必要的 API 端口；生产环境与开发/测试环境应严格分离；GPU 资源的访问应受限于授权的工作负载。
第三方管理： 如果使用 AIaaS（AI as a Service, AI即服务）平台或第三方推理服务，组织应（SHOULD）评估其安全控制措施的充分性，建议参考 ISO 42001（AI 管理体系）和 ISO 27001/27002（信息安全管理）框架进行供应商安全评估。
2.0.5. 静态数据保护 (Data at Rest Protection, DRP)
与 AI 系统相关的各类数据在存储时必须获得适当的保护。以下建议涵盖了 AI 生命周期中涉及的核心数据资产。
| 编号 | 建议 | 等级 |
|---|---|---|
| DRP-001 | 训练数据集的静态存储必须（MUST）采用加密保护，加密密钥应独立于数据存储系统管理。 | MUST |
| DRP-002 | 模型权重文件的静态存储必须（MUST）采用加密保护，访问权限应基于最小权限原则进行控制。 | MUST |
| DRP-003 | 用户与 AI 系统的交互历史记录应当（SHOULD）加密存储，包括输入 prompt（提示词）和模型响应。 | SHOULD |
| DRP-004 | 模型推理输出结果的存储，若涉及敏感信息，应当（SHOULD）根据数据的敏感级别实施相应的加密保护。 | SHOULD |
| DRP-005 | 用户提交的 prompt（提示词）在持久化存储前应（SHOULD）实施隔离存储，避免训练数据与用户输入混用同一存储空间。 | SHOULD |
| DRP-006 | 用于 RAG（Retrieval-Augmented Generation, 检索增强生成）的嵌入文档向量存储应（SHOULD）实施访问控制并加密存储。 | SHOULD |
| DRP-007 | 向量数据库和图数据库中存储的嵌入向量和关联元数据应当（SHOULD）实施加密保护，数据库的访问凭证应使用机密管理服务（如 HashiCorp Vault、AWS KMS）安全存储。 | SHOULD |
2.0.6. 数据交换加密 (Data Exchange Encryption, DE)
在 AI 生命周期的所有阶段，数据在传输过程中的机密性和完整性至关重要。组织必须（MUST）对以下数据传输通道实施加密：
- 训练数据从采集点到存储/预处理环境的传输；
- 模型权重从训练环境到模型仓库的传输；
- 推理 API 的客户端请求与响应；
- 模型监控数据从推理节点到日志/分析系统的传输。
上述传输应（SHOULD）使用 TLS 1.3（传输层安全协议第 1.3 版）或同等强度的加密协议，证书应由受信任的 CA（Certificate Authority, 证书颁发机构）签发。
2.0.7. 远程管理接口 (Remote Management Interfaces, MI)
AI 系统涉及的远程管理和运维接口必须（MUST）实施安全访问控制：
- 所有远程管理接口必须（MUST）使用强身份认证机制，推荐使用多因素认证（MFA, Multi-Factor Authentication）；
- 管理接口的通信应（SHOULD）使用专用管理网络或 VPN（虚拟专用网络）进行隔离；
- 管理会话应（SHOULD）实施超时自动注销机制；
- 所有管理操作应（SHOULD）记录到不可篡改的审计日志中。
2.0.8. 日志记录 (Logging, LOG)
完善的日志记录是安全事件检测、取证分析和合规审计的基础。AI 系统的日志应覆盖模型训练、部署、推理和退役各阶段的关键事件。
| 编号 | 建议 | 等级 |
|---|---|---|
| LOG-001 | 所有管理员操作（模型部署、配置变更、权限修改、数据删除等）必须（MUST）记录日志，包括操作人、操作时间、操作类型和操作结果。 | MUST |
| LOG-002 | 日志系统应（SHOULD）支持 syslog 协议（RFC 5424）或其他标准化日志转发协议，以与现有 SIEM（Security Information and Event Management, 安全信息和事件管理）系统集成。 | SHOULD |
| LOG-003 | 日志数据应（SHOULD）发送至多个独立的日志存储端点，防止单点故障导致日志丢失。 | SHOULD |
| LOG-004 | 日志传输通道必须（MUST）使用加密连接（如 TLS），防止日志在传输过程中被拦截或篡改。 | MUST |
| LOG-005 | 日志内容必须（MUST）排除敏感信息（如用户密码、API 密钥、个人身份信息和完整的推理输入输出），可通过日志清洗或脱敏机制实现。 | MUST |
| LOG-006 | 日志系统应（SHOULD）配置告警规则，当检测到异常事件（如未授权的模型访问、训练数据完整性校验失败、大规模推理异常）时触发即时告警。 | SHOULD |
| LOG-007 | 对训练数据、模型权重和配置的数据变更操作应（SHOULD）记录变更日志，包括变更前和变更后的状态，以支持完整的变更追踪。 | SHOULD |
2.0.9. 数据保留 (Data Retention, DR)
AI 系统涉及的数据保留策略需要在安全、合规和业务需求之间取得平衡。
| 编号 | 建议 | 等级 |
|---|---|---|
| DR-001 | 模型版本化必须（MUST）被实施，每个训练产出的模型权重应附带唯一的版本标识和关联的元数据（训练数据版本、代码版本、超参数）。 | MUST |
| DR-002 | 已废弃的模型版本在保留期满后应（SHOULD）被安全擦除，擦除操作应记录日志。 | SHOULD |
| DR-003 | 组织应（SHOULD）制定并执行数据保留策略，明确不同类型数据（训练数据、推理日志、用户交互记录、审计日志）的保留期限。 | SHOULD |
| DR-004 | 用户数据的保留时长应（SHOULD）支持用户可配置的选项，在无用户配置时应用默认保留期限。 | SHOULD |
| DR-005 | 用户请求删除其数据时，系统必须（MUST）支持在合理时间内完成数据删除，并确认删除结果。 | MUST |
| DR-006 | 当使用差分隐私（Differential Privacy）技术对训练数据进行隐私保护时，隐私预算（privacy budget）的使用情况应（SHOULD）被记录和监控。 | SHOULD |
| DR-007 | 安全审计日志的保留期限应（SHOULD）不短于相关法规或行业标准要求的最低保有时间。 | SHOULD |
| DR-008 | 事故响应（incident response）相关的模型快照、推理日志和配置快照应（SHOULD）在事故关闭后保留至少 90 天，以供事后分析和取证。 | SHOULD |
| DR-009 | 数据保留策略应（SHOULD）定期审查并在组织内部传达，确保所有相关人员了解其在数据处理和保留中的职责。 | SHOULD |
3. 结论
本文档概述了 AI 模型生命周期安全的最佳实践，重点覆盖了从训练数据采集、模型训练、测试、部署、数据保护、日志审计到数据保留的全链路安全管控。随着 AI 技术的快速发展，新的攻击面和威胁将持续涌现，组织应当建立持续监控和评估机制，定期审查和更新其 AI 安全实践。
本指南可与 NIST 网络安全框架（CSF）2.0 配合使用，将 AI 安全管控融入组织整体的网络安全治理体系中。建议实施者关注 M3AAWG、NIST、ISO/IEC、ETSI 等机构发布的最新指南和标准更新。
4. 术语表 (Glossary of Terms)
| 术语 | 英文 | 说明 |
|---|---|---|
| 个人身份信息 | PII (Personally Identifiable Information) | 可用于直接或间接识别特定个人身份的信息，如姓名、身份证号、电话号码、邮箱地址等。 |
| 人工智能 | AI (Artificial Intelligence) | 能够执行通常需要人类智能的任务的系统或技术，包括学习、推理、感知和决策等能力。 |
| 软件即服务 | SaaS (Software as a Service) | 一种软件分发模式，用户通过互联网访问云服务商托管的应用程序，无需本地安装。 |
| AI即服务 | AIaaS (AI as a Service) | 将 AI 能力以云服务形式交付的模式，用户通过 API 调用获得推理、训练等 AI 功能。 |
| 公钥基础设施 | PKI (Public Key Infrastructure) | 一种用于创建、管理、分发和撤销数字证书的框架和系统，用于验证数字身份和加密通信。 |
| 差分隐私 | Differential Privacy | 一种隐私保护技术，通过向查询结果中添加受控噪声，确保单个数据记录的存在与否对分析结果影响有限，从而保护个体隐私。 |
| 红队测试 | Red-Team Testing | 由安全专业人员模拟真实攻击者的行为，系统性地测试和评估系统安全防护能力的对抗性测试方法。 |
| 软件物料清单 | SBOM (Software Bill of Materials) | 一份详细列出软件组件、依赖关系和版本信息的清单，用于软件供应链的安全管理和漏洞追踪。 |
| 检索增强生成 | RAG (Retrieval-Augmented Generation) | 一种将信息检索与语言模型生成能力相结合的架构，模型在生成响应前先从外部知识库检索相关上下文。 |
| 提示词 | Prompt | 用户向 AI 系统提交的输入指令或查询文本，用于引导模型生成对应的输出。 |